People must be able to revoke a single remote session
Aliases: kick device · revoke session · remote sign-out
What it is
After seeing a stranger session, someone needs to end that one row without changing the password and without kicking every device at once. Remote revocation of a single session means the server immediately voids that session’s refresh and access tokens; the target device returns to signed-out on its next request; other sessions stay. This entry is selective invalidation. It does not care how the list looks, and it does not care whether unusual sign-ins are pushed. It is also not tapping Sign out on this device—that is a different path.
Why it happens
Once a token is on a device, the holder need not prove identity again. A sold phone, a shared computer, a stolen tablet leave a still-honored grant. Offering only “sign out everywhere” also kicks the person’s own laptop, a cost high enough that they will not use it; offering only a password change upgrades a lost device into a whole-account crisis. Single-row revocation matches remedy granularity to threat granularity. Invalidation must take on the server: deleting a row from the list while the token still calls the API is fake revocation. The target device should see “signed out elsewhere,” not a network error, or people will treat it as a glitch, sign in again, and mint a fresh token.
Studying it
Plant a session that should no longer live, and compare single-row revocation, revoke-all, and password-change-only: does the threat session die, do the person’s other sessions remain.
Independent variables: revocation grain (one, all, none), whether refresh tokens are included, copy on the target device. Dependent variables: whether later API calls with the revoked session still succeed, whether the person’s other devices stay signed in, whether people will act on a stranger row.
In the lab both sessions belong to the participant, so emotional cost is low. Under a real threat people fear tapping the wrong row. Measure the misfire of revoking the current session by mistake. Disappearing from the list is not success—call the API with that token.
Where it stops holding
Revoking the current session is local sign-out; the control should not let people kick themselves from the list without confirmation. Some refresh-token families cannot be revoked per session; engineering must be able to revoke by session id or this interaction cannot be kept. Enterprise compliance may forbid users kicking managed sessions; the entry should say to ask an admin. Invalidating every session after a password reset is recovery insurance, not a substitute for everyday single-row kicks.
Applying it
- Give every non-current session “sign out this device”; on confirm, revoke that session’s access and refresh tokens immediately.
- On the kicked device’s next foreground request, show “signed out on another device,” not a generic network failure; do not silently re-sign-in unless the person fully authenticates again.
- Offer “sign out all except this one” as a bulk action separate from single-row revoke, so the choice is not only all-on or all-off.
- Verify: after A revokes B, B’s token must fail an authenticated API; A and C still succeed. Then revoke the current session on purpose and confirm that is local sign-out, not leaving others in while this device stays. Spot-check that tokens are dead after the row vanishes.