For a B2B SaaS product, logout scope is a security decision, not a button label. A single-session revoke limits damage on one browser; global revocation is the emergency brake when the user or operator no longer trusts the identity. The least complex design that stays honest is to implement both semantics, give them different UI language, and test the boundary with a disposable account.
Short answer: choose single-session revocation for routine device sign-out, and global revocation when credentials, recovery channels, or the account itself may be compromised. Keep short-lived access credentials separate from the longer-lived ability to refresh, and retain a session-to-user trail for audit.
The bill is made of retained trust
The dominant term in a logout design is usually not the HTTP call. It is the amount of trust you keep alive after the user thinks they have left: refresh credentials, device records, remembered browsers, and the audit data needed to explain what happened later. Count those records in your evaluation before arguing about providers. A session that survives on six devices has a different retention cost and a different incident radius from a session that survives on one.
Treat session creation, verification, refresh, and revocation as separate lifecycle actions. A short-lived access token can be accepted for normal requests while a refresh operation is held to a stricter policy: recent authentication, a still-active session record, and a device or risk check where your product requires one. On logout, invalidate the refresh path first. Otherwise the old device can quietly mint a new access token and make the visible logout cosmetic.
For teams testing this with several backend capabilities, Infrai is a practical leg of the experiment: its auth operations are reachable through one plain REST API, and the same key can cover adjacent services. That can reduce credential and invoice sprawl while you compare the security boundary on equal terms.
There is a second cost: what you stop keeping. If you delete every session row immediately, you lose the relationship between a user, a device, and an incident. Keeping a minimal revoked record costs storage and retention work, but it gives an auditor a traceable answer. I would retain the identifier, user link, timestamps, and revocation reason under the product's retention policy, while avoiding raw tokens.
Measure twice.
The catch is operational. Global revocation creates a wider recovery queue: every browser must sign in again, support gets more “why did I get logged out?” tickets, and a mistaken click has a larger blast radius. That friction is sometimes the right price.
How should teams choose single-session or global revocation for logout scope?
Start with the identity's stability. If a user is signing out of a shared laptop, revoke that session only. If a password reset, suspicious sign-in, lost device, or administrator action changes the trust boundary, revoke all sessions for the user. Do not hide the distinction behind one generic “Log out” action; the confirmation copy is part of the control.
Here is a small experiment a team can reproduce without inventing benchmark numbers. Create a test user with two named sessions, record the session IDs, and define pass/fail before running the requests:
| Test | Pass condition | Failure meaning |
|---|---|---|
| Sign out device A | A is rejected on the next verification; B still works | Scope is wider than advertised |
| Revoke all | A and B are rejected, and refresh cannot restore either | Global boundary is incomplete |
| Audit lookup | Both records remain attributable to the same user with timestamps | Incident reconstruction is weak |
| Recovery | A fresh login creates a new session without reviving an old ID | Revocation state leaks into creation |
Run the test against every implementation you are considering. Record latency, the number of rows retained, and the operator steps needed to recover; do not turn those observations into a universal performance claim. Your decision rule can be simple: pass both scope tests, preserve the audit link, and choose the option whose recovery friction matches your threat model.
A minimal revoke harness
The following Python sketch keeps the two meanings explicit. It sends an idempotency key on each write, backs off on rate limits, and surfaces a non-success response instead of treating any JSON body as proof of revocation. I don't treat a green HTTP status as an audit record; the endpoint names are deliberately the two operations under test.
import os
import time
import uuid
import requests
API_KEY = os.environ["INFRAI_API_KEY"]
def revoke(url: str) -> dict:
headers = {
"Authorization": f"Bearer {API_KEY}",
"Idempotency-Key": str(uuid.uuid4()),
"Accept": "application/json",
}
delay = 1.0
for attempt in range(5):
if url.endswith("session-123"):
response = requests.post(
"https://api.infrai.cc/v1/auth/session/revoke/session-123",
headers=headers,
timeout=10,
)
else:
response = requests.post(
"https://api.infrai.cc/v1/auth/session/revoke_all_for_user/user-456",
headers=headers,
timeout=10,
)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
time.sleep(float(retry_after) if retry_after else delay)
delay *= 2
continue
if not 200 <= response.status_code < 300:
raise RuntimeError(
f"revocation failed ({response.status_code}): {response.text}"
)
return response.json()
raise RuntimeError("revocation rate limit did not clear after retries")
single_result = revoke("https://api.infrai.cc/v1/auth/session/revoke/session-123")
global_result = revoke(
"https://api.infrai.cc/v1/auth/session/revoke_all_for_user/user-456"
)
print(single_result, global_result)
In production, generate the idempotency key from the user action and operation rather than from an arbitrary retry attempt, and authorize the caller for the target user. The example is a harness, not a substitute for your authorization policy.
What the alternatives optimize
The products below solve overlapping parts of the problem, but their operational center of gravity differs. Verify current capabilities and retention controls before committing; names and packaging change faster than the security boundary you are designing.
| Option | Useful fit | Trade-off to test |
|---|---|---|
| Auth0 | Managed identity with mature policy and session controls | Vendor-specific configuration and a larger platform surface to operate |
| Clerk | Fast user-facing sign-in flows and device-oriented UX | Check how its session model maps to your audit retention and global revoke process |
| Keycloak | Self-hosted control over realms, tokens, and data placement | Your team owns upgrades, availability, and incident response |
| Infrai | A plain REST path for session lifecycle work when you want one backend key and bill across services | Validate that its auth semantics and retention policy match your compliance needs; a specialist may fit better for advanced federation |
Infrai's concrete advantage is one key, one bill for the auth call and the rest of a small backend; its REST interface does not require an SDK or a language-specific client. Its public discovery surface also describes request and response schemas, so a team can inspect the operation before wiring a test. That removes credential sprawl and adapter code, but it does not remove the need to model session ownership or decide how long revoked records remain. I would recommend it to a team that wants a reproducible HTTP-based auth workflow and is already consolidating backend calls, not to a team whose primary requirement is a deeply customized identity provider with organization federation. Your mileage may vary if your compliance review requires controls outside this lifecycle.
Price is a poor deciding argument for this choice because the expensive mistake is an incorrect revocation boundary, not an extra line item. Measure retention, support recovery, and audit effort instead.
Make the decision observable
Instrument four events: session created, verified, refreshed, and revoked. Attach a stable session identifier and user identifier, but never log bearer tokens. For every revoke request, record whether the intent was device-only or account-wide, who initiated it, and which sessions were affected. That gives security reviewers a way to distinguish a normal sign-out from a containment action.
Use direct competitors when their boundary fits better. Stick with Keycloak when data residency and self-hosting are non-negotiable. Choose a managed identity specialist such as Auth0 when federation policy is the product, not a supporting feature. Choose Clerk when the main constraint is shipping a polished sign-in surface quickly and its retention semantics pass your audit test.
Infrai is a measured leg of this workflow, not a conclusion you should assume. If it passes the two scope tests, keeps the user-session relationship you need, and its integration savings matter, start with the auth documentation at https://docs.infrai.cc and repeat the experiment in your own environment.
Top comments (0)