Local logout and provider sessions

What signing out ends

The printer's Sign out button ends the session the printer created after your sign-in. As Staying signed in described, that takes two steps: deleting the session record on the printer's server, and removing the cookie that pointed to it. The printer's response replaces the cookie with an empty one that has already expired:

HTTP/1.1 303 See Other
Location: https://printer.example/signed-out
Set-Cookie: __Host-printer-session=; Path=/; Max-Age=0; Secure; HttpOnly; SameSite=Lax

The empty cookie repeats the original attributes because a browser accepts a __Host- cookie, even one that deletes another, only with Secure, Path=/, and no Domain. Deleting the server record is the step that matters most. If a copy of the old cookie value survived somewhere, in the shared computer's memory or in a log, it would now find nothing.

Anything the printer kept for the session goes with it. Establishing an application session described that record: your account, the issuer, your subject, when you authenticated, and a copy of the ID token for signing out later. The access token demo-access-token-12 was never part of it. The printer used that token once to read your profile from the UserInfo endpoint and did not keep it.

One thing should survive. If you also set up the yearly calendar, the printer holds a refresh token so that it can collect photos in December. That connection is an authorization you granted, not a sign-in, and Offline access and refresh behavior explained why the two are kept apart. Signing out of a website should not quietly cancel next December's calendar. Disconnecting your photo account is a separate choice the printer offers on its own.

Ending the application's own session like this is called local logout. The printer can do it completely and reliably, because it controls everything involved. It is also all the printer has done.

The session you left behind

At 09:50 the next person at the library computer opens the printer and selects Continue with your photo account. The printer sends the browser to the photo service, exactly as it did for you. The photo service finds its own session cookie in the browser, set when you signed in at 08:59:45, and its policy accepts a session that recent without asking again. It issues a fresh ID token for user-2048 and sends the browser back.

The printer validates that token, and every check passes. The signature is genuine, the issuer and audience are right, and the nonce matches the new attempt. The printer signs a stranger in to your account. Nothing was forged. The printer ended the session it controlled and left the photo service's session running in the same browser.

Single sign-on made your morning easy, and the same convenience is at work here. Trust across systems pointed out that signing out of one application does not end the identity provider's session, or the sessions of other applications that relied on it. By the time you leave the library, the browser can hold several sessions, each with its own owner:

The ID token is not on that list. Its exp passed at 09:05 without changing anything, because an ID token describes one sign-in and is not a session. Application accounts and sessions described these as independent lifetimes; the library is where that independence starts to hurt.

To coordinate across those sessions, the printer and the photo service need a way to name the photo service's session, not just your account. Establishing an application session said to store sid whenever an ID token carries one, and this is what it is for. Providers that send logout notifications give each of their sessions an identifier and place it in ID tokens as the sid (session ID) claim. The photo service does this for clients registered for its notifications, so the printer registers a back-channel logout address with it, for the server-to-server notice that Back-channel logout describes. From then on an ID token like the one from your 09:00 sign-in carries one more claim:

{
  "iss": "https://auth.photos.example",
  "sub": "user-2048",
  "aud": "photo-printer",
  "iat": 1790845200,
  "exp": 1790845500,
  "auth_time": 1790845185,
  "nonce": "demo-nonce-3",
  "sid": "demo-session-51"
}

The value is opaque. The printer does not try to parse it, and it means something only together with the issuer, since another provider could use the same string. The printer stores it in the session record beside iss and sub. Later, a message about session demo-session-51 at https://auth.photos.example can be matched to your session at the printer, and a sign-out request from the printer can tell the photo service which of its sessions it means.

Choosing what logout means

The library shows what goes wrong when a sign-out ends less than you expect. The opposite happens too. At home, you might sign out of the printer while you are still sorting photos at the photo service in another tab. If the printer's Sign out also ended the photo service's session, you would be signed out there without warning, along with every other application that depended on it.

Consumer services usually keep local logout as the meaning of Sign out and offer the wider choice openly. The printer can tell you that you are still signed in to the photo service and offer to sign you out there too, which matters most on a shared computer. The photo service, for its part, normally asks before ending its own session, because it knows better than the printer what else you are using.

Organizations tend to want more. When a designer at Lantern Studio signs out of the portal at the end of the day, Lantern expects the session at its identity provider to end and the timesheets application to sign out as well, so the next person at the workstation finds nothing open. When a designer leaves Lantern, an administrator expects every one of their sessions to end at once, without waiting for the designer to click anything. Ending the sessions at several applications from one event is often called single logout.

OpenID Connect provides four mechanisms for these goals, each defined in its own specification:

The first answers the library problem: the printer asking the photo service to end its session too. The other three carry the news from the provider to applications that did not start the sign-out. Which ones a deployment uses depends on its applications and on what its provider supports. None of them can guarantee that every message arrives, so each application keeps its own idle and absolute timeouts as a limit on how long a missed sign-out can matter.