Signing out everywhere

Why is leaving harder than arriving?

Signing in feels like the hard part. You prove who you are, a second factor is checked, a session appears. Signing out feels like the easy inverse: throw the session away. Yet "sign me out of every device, now" is a genuinely difficult feature that large identity products have spent years improving, and one that often does not take effect instantly.

That asymmetry is worth sitting with. If arriving and leaving were mirror images, they would cost the same. So what is different about the two directions?

The difference is where the evidence lives. When you sign in, exactly one party has to be convinced, and it is convinced at that moment: the identity provider checks your credential and then issues something. From then on, the thing it issued travels. It gets copied into a browser cookie, into a mobile app's keychain, into a server-side session store, into a background worker that holds a refresh token, and — if it is a self-contained token — into the memory of every service that has verified it.

Now ask the question that makes the asymmetry obvious: to sign out, whose mind must you change? Every one of those holders. Arriving is a single act of creation; leaving is an attempt to reach every copy that act produced. And copies do not sit still.

There is a deeper constraint underneath. A signed token that a resource server can validate offline — by checking a signature and an expiry, with no call home — is the whole reason modern APIs scale. That property and instant revocation are in direct tension: something you can verify without asking anybody is also something nobody can retract by telling you. You cannot have offline verification and immediate global revocation from the same artefact. That is not an implementation gap; it is the design trade being paid for.

So what do real systems do? Several things at once, and each covers a different copy.

The identity provider ends its own session, so no new tokens are minted from it. OpenID Connect adds a logout family for the applications: RP-initiated logout, where the app sends you to the provider's logout endpoint; front-channel logout, where your browser loads a hidden iframe per application to clear each local session; and back-channel logout, where the provider posts a signed logout token — carrying the session id or subject — directly to each application's registered endpoint. Front-channel is the fragile one, because it depends on the browser loading third-party frames and sending their cookies, which browsers now increasingly partition or block.

Then there are tokens rather than sessions. OAuth defines a revocation endpoint (RFC 7009), and revoking a refresh token is the highest-value action available, because it stops the renewal loop — the client cannot mint another access token. But the access token already out there stays cryptographically valid until it expires. Hence the standard mitigation: keep access-token lifetimes short, so the exposure window is minutes rather than hours.

If minutes are too long, the resource server has to stop verifying offline. It can call the introspection endpoint (RFC 7662) to ask whether the token is still live — correct, and a network call on every request. Or it can subscribe to revocation events: the Shared Signals framework and its Continuous Access Evaluation Profile define exactly this, a stream of session-revoked and credential-changed events pushed to relying parties so they can drop a session before its token expires. Push is faster than polling, but it is still eventual, and it fails quietly when a receiver is offline.

And notice what remains uncovered even then: anything already handed out that is not a token. A downloaded file, an open WebSocket, a pre-signed URL, a cached page. Signing out ends future authorisation; it does not recall what was already given.

Three refinements.

First, "signed out" is not one state. Ending the provider's session, ending each application's session, revoking refresh tokens, and invalidating live access tokens are four separate outcomes, and a product that does the first often advertises all four. Worth checking which ones your stack actually performs, because the audit answer to "was that person's access removed at 14:02?" depends entirely on which.

Second, short token lifetimes are not a workaround to be embarrassed about; they are the primary control. Everything else — introspection, event streams, revocation lists — is machinery for shrinking a window that expiry would eventually close anyway, and each piece buys speed with a dependency.

Third, a misconception worth correcting: revoking a token does not undo anything the token did. A session that copied data out, or started a long-running job, leaves that behind. Revocation is a statement about the future, which is why audit logs, not the revocation itself, are what answer the question of what happened while access was live.

• Why short access-token lifetimes plus refresh-token rotation is the default answer, and what rotation detects.
• The Shared Signals framework and Continuous Access Evaluation, and how a receiver catches up after being offline.
• Session fixation and the mirror-image problem: making sure a new session cannot inherit an old one's identifier.

Every term the collection defines is gathered in the glossary.