Token Management
What this screen is for
Every access token the platform issues carries a unique identifier, its JTI. When a token is revoked before it expires, that identifier is written to a blacklist that every service consults on every request, and the token is refused from then on. This screen lists the entries of that blacklist that belong to your tenant, under the heading Revoked Tokens, with a total and a Refresh button.
Read the heading literally. This list holds tokens that are already revoked and no longer valid; its one action acts on an entry already in it. The screen also shows the open sign-in sessions of a member of your tenant, and lets you end them.
Whatever language the console is set to, this screen's labels are in English.
What must exist first
Both SIMPLE and STANDARD tenants use this screen, on every deployment type. Before you work here:
- The permission to read your tenant's tokens, which shows the sidebar entry, the list and a member's sessions. The built-in tenant administrator, access administrator, auditor, key manager and viewer roles hold it. Without it the screen says you do not have permission to view token management.
- The permission to revoke your tenant's tokens, held by the built-in tenant administrator role, which adds the Action column and lets you end a member's sessions.
- To choose a member in Sign-in sessions, also the permission to list your tenant's users (
admin.tenant.user.list). The five built-in roles above hold it; a custom role that reads tokens without it shows the list of revoked tokens but not the member picker, and the screen says choosing a member requires theadmin.tenant.user.listpermission.
Decisions you make here
Reading the list
Each row is a JTI, shown in full, with the badge Revoked. Nothing else is shown: not whose token it was, not when it was issued, not whether it belonged to a person, a cryptographic actor or a support session. The platform keeps only the identifier and the tenant it was issued to. The list is capped at 5,000 entries and says Showing first 5,000 entries when the cap is reached; Total revoked counts what was returned.
What appears here is every token of your tenant whose revocation was written to the blacklist: a console session ended by signing out, a token revoked through the API by its own holder, a support session ended by the operator or by your withdrawal, and any token revoked from this screen. An entry disappears when the token it names would have expired anyway, because the platform stops remembering a token past its own lifetime.
What does not appear here: tokens that simply expired; refresh tokens, which are deleted rather than blacklisted; and sessions ended by taking a role away, removing a user or unlinking a federated identity. Those are ended through a per-person revocation mark that this list does not read, so a person you removed is not represented here even though every session they had is over.
Revoking an entry
With the revoke permission, the trash icon of a row opens Revoke Token, which says it will immediately invalidate the token. The request repeats a revocation that already stands: the entry is rewritten to be remembered for 30 days, and the token stays refused exactly as before. It cannot be undone, and there is nothing further it could stop, because the token was already stopped. The revocation is written to your authentication audit trail; so is every read of this list.
The request is refused, and the screen reports that the token could not be revoked, when the platform no longer knows which tenant the token belonged to. That happens once the token has passed its own expiry, so the row is on its way out of the list regardless. It is not refused because the token was already revoked: repeating a revocation succeeds.
To end access that is still valid, go where the identity lives. Removing a user or taking a role away ends every session that person has; revoking a credential stops the actor presenting it; withdrawing a support authorisation ends every support session under it.
Ending a member's sessions
In Sign-in sessions, choose a member to list their open sessions in your tenant: when each began, how the person signed in, its last activity, when it ends at the latest, and whether it is remembered. Sessions the person holds in other organizations are never shown or touched.
The identity provider a session signed in through is shown only for a password sign-in or a provider of your tenant: its own, or the deployment's provider it uses. A session that began at another organization's provider and then switched into your tenant shows no provider, so that organization's provider is never disclosed to you.
With the revoke permission, End session ends one session, and End all of this member's sessions in this tenant ends every session the member has here. The person can sign in again while their membership is active. Each action is written to your authentication audit trail, naming you and the member.
A session also ends by itself: at most 12 hours after sign-in by default, and earlier after a period without activity.
When a revocation takes effect
Every service checks the blacklist after it has verified a token's signature and expiry, on every request and without caching a clean answer. A revoked token is therefore refused on the very next request it is presented with, wherever it is presented. If the blacklist itself cannot be reached, the token is refused rather than admitted.
How it relates to other screens
The revoked list records the aftermath of revocations decided elsewhere. A person's sessions end here or on the users screen, and an actor's on the actors screen; a support session ends from the Support Access screen or when its window closes. When a member last signed in to your tenant is shown on the users screen. The authentication trail, including each revocation made here, is part of your tenant's audit log: