Backed by: @pithy-sh/auth. Scopes: auth:users:read · auth:devices:read · auth:sessions:revoke · auth:users:logout · auth:devices:revoke.
What it shows
Sessions and devices is what a row here is, the token model is what revoking one actually kills, roles and permissions is who may, and the audit trail is where it is recorded.
The index lists users. The record shows one, with their sessions and their registered devices.
Fetched live from your D1 and discarded. Nothing is stored here.
What you can do
Revoke one session. Sign a user out everywhere. Revoke a device.
Each is a separate scope, so a support role can be given sign-out without being given device revocation.
No impersonation
Devices are what makes sign out my old phone answerable
A device is durable across every rotation; a session is one live credential.
Revoking a device deletes every session bound to it, then forgets the device — and the response is a count, which can legitimately be more than one.
Only registered devices appear. A client that never sends the device header signs in perfectly well and shows no device — that is an ordinary web session, not a gap.
Language is on the user row
locale is nullable, and null means this reader has never chosen — not English.
That distinction is the column’s whole purpose: null falls through to the browser’s own preference, and en asserts a choice nobody made.
What the dashboard cannot see
A password, because there are none — the kit is passwordless throughout.
A token’s value. Sessions are rows; access tokens are short-lived and not stored.
Every action here is audited
In your trail, under the control-plane actor kind, carrying the connection id and the dashboard user’s own subject.
So what did the management client do is a question your own database answers, separately from what your users did.
Denials are audited too, and this is a surface where an unaudited blocked attempt would be least acceptable.