Short answer: use single-session revocation for a routine logout, and use global revocation when there is credible account compromise, a reset, or an audit-mandated kill switch. The choice is a security boundary, not a button label.
In an edtech system, a learner may be signed in on a phone, a shared family laptop, and a school Chromebook. A forgot-password flow must prove which sessions survived and which did not. I treat that proof as part of the feature, alongside delivery and rate-limit evidence.
What should single-session and global revocation protect?
Start by naming the invariants. A logout request must invalidate the presented session credential quickly, be safe to retry, and leave an audit event with actor, target account, session identifier (or a privacy-preserving hash), timestamp, and reason. A password reset must invalidate every credential that could still authorize the old password. Those rules are stronger than “delete a cookie.”
The failure boundary is usually a token store, not the browser. If access tokens are self-contained and live for 15 minutes, deleting a server-side session row does not revoke an already issued token unless every request checks a revocation marker or the token lifetime is deliberately short. Refresh tokens need rotation and reuse detection; otherwise a copied refresh token can mint a fresh session after the visible logout.
Here is the decision record I use with an audit team:
| Event | Scope | Why | Friction and evidence |
|---|---|---|---|
| User taps logout on one device | Single session | Preserve other trusted devices | Lowest friction; record the session and request metadata |
| User completes forgot-password reset | Global account | Old credentials may be copied | Forces re-authentication everywhere; record reset completion and revocation version |
| Suspicious login or support-confirmed takeover | Global account | Contain unknown sessions | High friction; require step-up checks and notify the learner |
| Lost school Chromebook | Global account, then selective re-login | Device trust is uncertain | More disruption, but a clear incident trail |
The catch is that “global” should mean all server-recognized credentials, including refresh tokens and remembered-device grants. If a product cannot enumerate those credential classes, its logout promise is narrower than its UI suggests.
How do you choose the right logout scope for an audited forgot-password flow?
Use the event, not the user's wording, as the selector. A normal logout proves intent to leave one session. A password reset proves that the account secret changed; retaining another session silently defeats that change. Support tooling should therefore expose a global action only behind authorization, a reason code, and a confirmation that names the blast radius.
The critical path can stay small. This Python sketch uses generic interfaces so the policy remains portable across session stores and identity providers:
from dataclasses import dataclass
@dataclass
class LogoutRequest:
account_id: str
session_id: str
reason: str
password_reset_completed: bool = False
compromise_confirmed: bool = False
def revoke_for_event(req: LogoutRequest, sessions, audit):
global_scope = req.password_reset_completed or req.compromise_confirmed
if global_scope:
version = sessions.bump_account_revocation(req.account_id)
scope = "account"
target = {"account_id": req.account_id, "revocation_version": version}
else:
sessions.revoke_session(req.account_id, req.session_id)
scope = "session"
target = {"account_id": req.account_id, "session_id": req.session_id}
audit.append("logout.revoked", {"scope": scope, "reason": req.reason, **target})
return scope
Every authenticated request compares its session's issue-time revocation version with the account version, or consults an equivalent deny-list. Make the comparison constant-time where secrets are involved, and fail closed if the authorization service cannot establish the session state. Idempotency matters: repeating the same request should produce a truthful audit event without resurrecting anything.
I keep one sharp test in the suite: issue two sessions, complete a reset through one, then call an endpoint with the other refresh token. The expected result is a clean re-authentication response, not a 500 and not a newly minted access token. A separate test logs out one device and verifies that the second device remains usable.
Which implementation details decide the audit outcome?
An auditor will ask for more than a green integration test. Store a revocation version or event sequence with enough retention to explain decisions after the fact. Include correlation IDs, but avoid putting email addresses or raw tokens in logs. Clock skew deserves a test, too: define whether a token issued at the exact reset timestamp is accepted, then implement that rule consistently.
Delivery is part of the threat model. If the reset link arrives late because an SMS provider throttles or a mail filter delays it, a learner can request several links. Only the newest nonce should work, and each attempt should be rate-limited with a generic response that does not reveal whether an account exists. I have seen teams chase a 429 from the messaging edge while forgetting that the older link still authenticated; the security fix is nonce invalidation, not a prettier error page.
Metrics should distinguish logout.session from logout.account, reset-triggered revocations, refresh-token reuse, and re-authentication loops. Alert on unusual global events per account and on a sudden rise in revocations after a deployment. Your mileage may vary on retention periods because school districts and jurisdictions set different requirements; document the policy owner and deletion schedule instead of guessing.
When is a different design the better choice?
A global kill switch is not suitable when users routinely share a kiosk account and a single learner's logout would interrupt a supervised class; in that case, isolate identities with short-lived, device-bound sessions and make the shared display non-sensitive. Single-session revocation is also a poor fit for a confirmed credential leak, because it leaves unknown copies alive.
The rejected option here is “always revoke globally.” It is easy to explain and hard to live with: every phone logout becomes a support ticket, offline coursework gets interrupted, and users start ignoring security prompts. Choose it only when policy requires universal sign-out, such as a confirmed takeover or completed password reset. Stick with single-session invalidation for ordinary exits, and make the escalation path explicit.
Top comments (0)