Implementing Sign Out Everywhere Across Devices

“Sign out of all devices” is the button users press when they think something is wrong, which makes it the worst possible place for a partial implementation. This page is part of the secure logout and session termination guide and covers what the operation must reach, in what order, and how to prove it worked.

Everything the Operation Has to Reach

A user’s access is spread across more places than a session table. Missing any one of them means the button reassures without protecting.

The Implementation

Work from the per-user session index, and treat the version counter as the mechanism that reaches everything you cannot enumerate.

export async function signOutEverywhere(userId: string, opts: { keepCurrent?: string } = {}) {
  const sids = await sessions.listForUser(userId);
  const doomed = sids.filter((sid) => sid !== opts.keepCurrent);

  await sessions.destroyMany(doomed);                 // 1 · server-side records
  await refreshTokens.revokeAllFamilies(userId);      // 2 · upstream credentials
  await users.incrementSessionVersion(userId);        // 3 · anything cached or self-contained
  await realtime.closeConnectionsFor(userId, doomed); // 4 · long-lived connections
  await audit.record("sessions.revoked_all", { userId, count: doomed.length });
  await notify.securityEvent(userId, "signed_out_everywhere", { count: doomed.length });

  return doomed.length;
}

The version counter is what makes this reliable. Any component holding a cached authorization decision or a short-lived token derived from the session compares the version it saw against the current one; a mismatch is a miss, with no broadcast and no cache flush. It is the same technique used for caching authorization decisions, and it is the difference between “we deleted the rows” and “access actually stopped”.

Decide deliberately whether the current session survives. Keeping it is friendlier — the user stays logged in on the device they are using — and is right when the trigger is a password change. Ending everything including the current session is right when the trigger is a suspected compromise, because the person pressing the button may not be the account owner.

Handling the Awkward Cases

Two categories resist enumeration and need their own handling.

Self-contained access tokens already issued cannot be recalled. If their lifetime is short — the five to fifteen minutes recommended in the refresh and rotation guide — the residual window is acceptable and expiry does the work. If it is longer, you need either a deny list consulted by resource servers or a version check on each request, and both are lookups you should have decided about before this feature was requested.

Long-lived connections need an explicit close. Keep a registry of active WebSocket and server-sent-event connections keyed by user, close them when sessions are revoked, and have the client treat an unexpected close as a signal to re-authenticate rather than to reconnect blindly. A connection that reconnects with a dead cookie will fail cleanly; one that reconnects with a cached token may not.

Making It Verifiable

Assert the outcome rather than the mechanism. In an integration test, create three sessions for one user, call the operation, then confirm that all three cookies return unauthenticated, that a refresh attempt with each family’s token fails, and that a request carrying a previously cached authorization decision is re-evaluated. Add a timing assertion — the last successful request using any revoked credential must precede the revocation — because that interval is the number an incident review will ask about.

Show the user the result. “Signed out of 4 devices” with a list of what they were is both a confirmation and a detection mechanism: a device the user does not recognise in that list is exactly what the feature exists to surface.

When the Operation Should Run Automatically

Users press the button rarely; the system should press it for them more often. Four events warrant an automatic sign-out everywhere, and each needs a decision recorded in code rather than left to convention.

A password change is the clearest. The usual motivation is suspicion that the old password is known, so leaving other sessions alive defeats the purpose entirely. Keep the current session, end everything else, and tell the user how many were affected.

Removing or replacing a second factor is the same argument one layer up: the authentication path that established those sessions no longer exists, so the sessions established through it should not either. The same applies when a passkey is deleted, because the credential that proved identity has been withdrawn.

A detected refresh-token reuse — the alarm described in detecting refresh token reuse with rotation — should revoke the family and end the associated sessions immediately. You cannot distinguish the attacker from the user at that moment, so ending both and forcing re-authentication is the safe resolution.

Finally, an administrator disabling or suspending an account must end everything at once. A disabled account whose existing sessions keep working is a control that exists on paper only, and it is the exact scenario an auditor will ask you to demonstrate.

Performance at Scale

For most accounts this operation touches a handful of records and completes in milliseconds. For a service account, a shared login, or an account under attack it can touch thousands, and the naive implementation — read all identifiers, delete keys one at a time, revoke each family individually — turns into a long-running request that times out halfway through and leaves the account in a partially revoked state.

Batch the work. Delete session keys in chunks, revoke families in bulk where your provider supports it, and make the whole operation idempotent so a retry after a timeout completes rather than restarting. Bump the version counter first rather than last: it is a single write, it immediately invalidates cached decisions and version-checked tokens, and it means a partial failure still leaves access curtailed rather than intact.

For genuinely large accounts, run the enumeration asynchronously and return promptly with a confirmation that the revocation is in progress, while the version bump has already taken effect synchronously. The user gets a fast, honest response and the guarantee lands immediately, with the slower cleanup following behind.

Return the count of sessions ended synchronously even when the cleanup continues in the background, because that number is what the user is actually asking for when they press the button, and producing it later leaves the confirmation screen with nothing useful to say.

Keep the asynchronous path observable: a queue depth that grows during an incident tells you the revocation is lagging, which is a fact you want on a dashboard rather than discovered afterwards.

Frequently Asked Questions

Triggers That Should Invoke It Automatically

Related

• Secure logout and session termination — the single-session case and its ordering rules.
• Managing session state in Redis — the per-user index that makes enumeration possible.
• Detecting refresh token reuse with rotation — revoking families rather than individual tokens.