Do Not Pretend a Row Revokes a JWT
Session UX is full of dangerous language. "This device is active." "Sign out everywhere." "Revoke session." Those phrases can mean radically different things depending on where authorization actually happens. If a backend accepts a valid JWT, deleting an application-level device row does not magically invalidate that token.
Vault uses Supabase Auth as the identity provider. Authorization stays centered around validated JWTs and workspace and resource rules rather than a custom stateful session layer. Device sessions exist alongside that model instead of replacing it.
That choice keeps the authorization path smaller and more honest. It also creates a clear limitation: revoking a Vault device-session record does not force another browser to log out of Supabase and does not invalidate an already valid JWT. The product should not imply otherwise.
What Device Sessions Track
The device-session table exists because visibility still matters. Users want to know where their account has been seen. Operators want audit context around login behavior, local devices, and cleanup. A lightweight record can answer those questions without becoming the source of backend authorization.
Device sessions provide visibility rather than authority. They help users understand where their account has recently appeared, which devices remain active, and whether something looks unfamiliar.
That visibility becomes useful during ordinary operational events: a lost laptop, a temporary machine, a suspicious browser session, or account recovery after a credential reset. These are hygiene and review workflows. They are not a replacement for the identity provider's token lifecycle.
Why Avoid Stateful Middleware?
A stateful session layer is not wrong by default. Some systems need it. But it changes the failure model of the entire API. Now every request depends not only on JWT validation and authorization rules, but also on the availability and correctness of a separate session system.
If session state becomes unavailable, should secret access fail? Should a missed heartbeat lock an engineer out of a deployment runbook during an incident?
Those are legitimate architectural choices. Vault intentionally chooses a smaller dependency chain. Authorization stays centered on Supabase JWT validation, workspace membership, secret visibility, explicit grants, and resource rules. Device sessions provide inventory and audit context.
What Users Gain
Users gain a practical session inventory. They can see where the account has recently appeared, identify the current device, and revoke the record for a device they no longer recognize. Operators gain a clearer account timeline through registration and revocation events.
The value is clearest when combined with other controls. If a laptop is lost, a user can review device sessions, change their identity-provider credential, rotate exposed secrets if there is reason to believe values were copied, and rely on workspace permissions to remove access where needed. The device list is one input to that response, not the whole response.
Audit the Statement, Not the Fantasy
The audit model follows the same honesty. Registering a device session is a session.register
event. Revoking one is a session.revoke event. Those are true statements about Vault's own
state. They do not claim that a Supabase token was invalidated, because that is not what happened.
This distinction sounds pedantic until an investigation depends on it. If a user revoked an unfamiliar device at noon and a valid JWT was used shortly after, the team needs to know whether that is expected under the architecture or evidence that something else happened. Precise semantics make review possible.
A Smaller Boundary Is Easier to Defend
The broader lesson is that not every security-adjacent feature should become authorization. Device sessions are useful because they make the account surface visible. They would become more powerful, but also more fragile, if every backend request depended on them.
Vault keeps the boundary smaller: identity from Supabase, authorization from JWT plus workspace and resource rules, device sessions for visibility, and audit logs for review. That architecture is less dramatic than a global "kill switch" button, but it is more honest about where power actually lives.