Short answer: treat global logout as an auditable state transition, not a single button. Take a point-in-time inventory of every session and refresh credential, revoke each eligible record, then prove after the event that old credentials cannot authorize a request. For a property-management system, that evidence matters as much as the redirect to the login screen.
A leasing agent may have a browser open at a front desk, a phone used for inspections, and a tablet shared with a maintenance vendor. A password reset or suspected account takeover must close all of them. The audit question is precise: which sessions existed, which were revoked, and what did a post-revoke probe observe?
The Decision Record: Define the Security Invariants
Start by writing invariants before choosing storage or framework details. A global logout operation should have one immutable event ID, an actor, a reason, and a timestamp from the service that owns authorization. It should cover browser sessions, mobile refresh tokens, remembered-device credentials, and any service-side session used for delegated work. If a credential type cannot be revoked, document that boundary instead of silently calling the operation complete.
The inventory is a snapshot, not a live query that changes while the audit runs. Capture a stable session identifier, credential family, issued-at time, last-seen time, device or client label, and revocation state. Keep token values out of the record; a hash or opaque identifier is enough to correlate evidence. Personally identifiable device data should have a retention policy.
The strongest invariant is negative: after the revoke time, an old credential must not obtain an authenticated response. A 401 proves rejection for that request. A successful response, even for a harmless endpoint, is a failed audit.
Here is the option comparison I use in an architecture decision record:
| Approach | Audit evidence | Failure boundary | Appropriate use |
|---|---|---|---|
| Per-session revocation rows | Exact record-level history and retries | Missed credential family if inventory is incomplete | Regulated or multi-device accounts |
| User-level session version | Cheap authorization check | Older services may not enforce the version | Homogeneous services under one middleware |
| Short token expiry only | Little state to operate | Logout is delayed until expiry | Low-risk, non-sensitive sessions |
| Remote introspection on every request | Central decision and fast disable | Availability and latency of the introspection service | High-value operations with a resilient control plane |
There is no universal winner. The property-management case usually needs per-session evidence, with a user-level version as a second guard for services that can enforce it consistently.
How Should a Session Inventory Support Global Logout and Post-Revoke Verification?
Model the audit as four timestamps: inventory start, revoke requested, revoke committed, and verification observed. They answer different questions. Inventory start bounds what you saw; committed tells you when the authorization store changed; observed tells you when an old credential was actually tested. Clock skew can make a report look impossible, so record server time and monotonic duration where available.
A useful workflow is:
- Freeze the inventory query at a transaction or a revision number.
- Mark the event as pending and attach the query revision.
- Revoke every credential in the captured families, making the write idempotent.
- Re-read each record and assert its state is revoked.
- Send a controlled request with each test credential and record the status, response class, and correlation ID.
- Close the event only when every required assertion has a result.
The verification request must be safe. Use a read-only endpoint that still requires authentication, never a destructive lease or payment action. A test can run from the same region and from a second region because a replicated authorization store may converge at a different time. Set a bounded deadline and label a timeout as inconclusive; do not turn it into a pass.
The following Python sketch keeps the protocol explicit. The interfaces are deliberately generic so the same audit can run against SQL storage, a cache-backed session service, or an authorization gateway.
from dataclasses import dataclass
from datetime import datetime, timezone
from typing import Iterable, Protocol
@dataclass(frozen=True)
class SessionRecord:
session_id: str
family: str
issued_at: datetime
revoked_at: datetime | None
class SessionStore(Protocol):
def inventory(self, user_id: str, revision: str) -> Iterable[SessionRecord]: ...
def revoke(self, session_id: str, event_id: str) -> None: ...
def get(self, session_id: str) -> SessionRecord: ...
class Probe(Protocol):
def authenticated_read(self, session_id: str) -> int: ...
def audit_global_logout(
user_id: str, event_id: str, revision: str, store: SessionStore, probe: Probe
) -> dict:
records = list(store.inventory(user_id, revision))
revoked = []
for record in records:
store.revoke(record.session_id, event_id)
current = store.get(record.session_id)
if current.revoked_at is None:
raise RuntimeError(f"revocation not visible: {record.session_id}")
revoked.append(record.session_id)
checks = []
for session_id in revoked:
status = probe.authenticated_read(session_id)
checks.append({\"session_id\": session_id, \"status\": status, \"accepted\": status < 400})
return {
\"event_id\": event_id,
\"user_id\": user_id,
\"inventory_revision\": revision,
\"verified_at\": datetime.now(timezone.utc).isoformat(),
\"checks\": checks,
\"passed\": all(not check[\"accepted\"] for check in checks),
}
In production, replace the exception with a durable failed assertion and continue checking the remaining sessions. Otherwise one malformed record can hide a second failure. Also make the revoke operation idempotent: retries happen after worker crashes, and a retry must not create a second contradictory history entry.
Failure Modes That Fool an Audit
The common miss is inventory scope. Teams revoke the web-session table while refresh tokens live in a separate credential store. Another miss is an old access token that remains valid because resource services validate its signature but never consult revocation state. Signature validity is not session validity.
Race conditions are quieter. A request can be authorized just before the revoke commit and finish afterward. Define the boundary in the report: requests accepted before the commit are in-flight, while new authorization decisions after the commit must reject the credential. Correlation IDs and authorization-decision timestamps let an auditor distinguish that race from a real bypass.
Cache invalidation deserves its own assertion. In one audit run, I traced a rejected database lookup to a still-warm regional cache: the session row had a revocation timestamp, but the authorization worker had not consumed the invalidation event yet. The useful evidence was the event ID, publish time, consumer time, and the first probe that returned 401. That chain made the boundary visible to reviewers and gave operations a concrete lag value to alert on. If a session is cached for 60 seconds, a database row changing to revoked does not automatically change an already-materialized authorization decision. Either publish an invalidation event with a measurable delivery guarantee or include a short-lived version check in the decision path. I am not sure a single global cache SLA can cover every region; your mileage may vary, so capture observed propagation time instead of promising an abstract number.
Do not use a login redirect as proof. Redirects are presentation. The authorization layer must reject the credential, and the audit store must retain the response evidence.
Operating the Evidence Without Leaking Secrets
Store an append-only audit record with the event ID, actor, reason code, inventory revision, count by credential family, revoke outcomes, probe outcomes, and final disposition. Hash session identifiers before putting them in logs that a broad operations team can search. Never log bearer tokens, cookie values, or full authorization headers.
Alert on a failed or inconclusive verification, not only on a failed revoke write. A worker that cannot reach the probe endpoint has not demonstrated safety. Keep the raw probe response metadata long enough to support the retention policy, then retain a compact decision record for trend analysis.
Test the process in deployment pipelines with synthetic users and two credential families. Include a session created during the revoke window, a duplicate retry, a delayed cache invalidation, and a region that reads from a replica. These cases expose more than a happy-path integration test.
The catch is operational cost: per-session evidence creates storage, retention, and retry work. It is not suitable when you have no reliable inventory owner or cannot protect the audit log. In that situation, stick with a simpler user-level session version until ownership and observability exist; claiming complete logout without those controls is worse than declaring a narrower guarantee.
Rejected Option and Boundary
I rejected “delete the user row and let foreign keys clean up sessions” as the primary design. It couples authentication safety to account lifecycle, destroys the evidence needed for an audit, and still misses credentials held outside that database. It can be valid for a deliberate account-erasure workflow when legal retention rules require deletion and a separate security event preserves the necessary proof.
Global logout is therefore a verification problem. The button is the easy part.
Measure it. The defensible result is a bounded inventory, idempotent revocation, authorization-layer rejection, and evidence that another engineer can replay without seeing a secret.
Top comments (0)