Global Token Revocation Guide: Logging Out Users, Services and Agents Everywhere at Once

Disabling an account at the identity provider does not log anyone out: refresh tokens, application session cookies and cloud role sessions already issued keep working until they expire, and for many SaaS apps that is days or weeks. Global token revocation, which Okta markets as Universal Logout, is the attempt to close that gap with one authenticated call from the identity provider to every downstream application, telling it to kill all sessions and refresh tokens for a named user. This guide explains the Global Token Revocation Internet-Draft, how it differs from OAuth token revocation, OpenID Connect back-channel logout and CAEP, how to build a revocation runbook that also covers service accounts, cloud roles and AI agents that the standard does not reach, and how to measure whether "logged out everywhere" is actually true. It is written for identity architects, incident responders and SaaS engineering teams who must either send or receive revocation requests.

Key takeaways

• Disable is not revoke. Microsoft documents that after disabling a user and revoking Entra refresh tokens, access tokens stay valid until expiry (one hour by default) and Entra cannot revoke session tokens issued by applications themselves.
• The standard is a draft, and an expired one. draft-parecki-oauth-global-token-revocation-06 is an individual Internet-Draft, latest revision 24 February 2026, shown as expired on the IETF Datatracker when checked on 11 November 2026; Okta's Universal Logout implements it.
• A 204 is not proof. The draft says HTTP 204 means revocation has begun, refresh tokens MUST be revoked, and revoking access tokens is not required for a success code, so verify outcomes in each app's logs.
• Machines need their own kill paths. The draft identifies users by email, opaque ID or issuer and subject; cloud role sessions, API keys, personal access tokens and agent credentials need per-platform revocation steps such as AWS "Revoke active sessions".
• The revocation channel is itself a weapon. A stolen revocation credential can log out a whole workforce, so scope it per tenant, sign requests with private key JWT and alert on bulk revocations.

Why logout does not propagate

Single sign-on centralises login but not logout. Once an application has accepted a SAML assertion or OIDC ID token, it usually issues its own session cookie and, for API and mobile clients, its own refresh tokens. The identity provider has no record of those credentials and no default way to cancel them. Three layers of credential survive an account disable:

Attackers rely on this. Session cookies stolen by infostealers (MITRE ATT&CK T1539 Steal Web Session Cookie) and OAuth tokens taken from integrations (T1528 Steal Application Access Token, used later under T1550.001 Application Access Token) do not care that the password was reset. The CircleCI breach began with a stolen SSO session on an engineer's laptop, which bypassed MFA because the session was already authenticated. See the Token and Session Security Guide and the Infostealer Logs and Session Token Abuse Guide for the theft side.

The Global Token Revocation draft

The draft, authored by Aaron Parecki, defines a single endpoint on an authorisation server that a trusted party, typically an identity provider or a security incident management tool, can call to revoke all of a user's existing tokens and require re-authentication. Status when checked on 11 November 2026: individual Internet-Draft, version -06, latest revision 24 February 2026, marked expired on the Datatracker, not adopted by a working group and with no formal IETF standing. Details may change if it is revived, so build to it but keep the integration replaceable.

Endpoint and discovery

• Endpoint: an HTTPS POST endpoint on the receiving application's authorisation server.
• Metadata: the server SHOULD publish global_token_revocation_endpoint in its OAuth authorisation server metadata, optionally with global_token_revocation_endpoint_auth_methods_supported. It may instead register the URL directly with each caller.

Request

• Body: application/json with one property, sub_id, a Subject Identifier as defined in RFC 9493 (Subject Identifiers for Security Event Tokens). The draft's examples use the email, opaque and iss_sub formats.
• Authentication: the request MUST be authenticated. Private key JWT is recommended; the JWT carries iss, sub, aud (the exact endpoint URL), jti, iat and exp, with a recommended five-minute validity and an asymmetric signature such as RS256 or ES256. The receiver checks the signature, audience and expiry and SHOULD reject a reused jti.
• Okta's profile: Okta's Universal Logout documentation identifies the user by email by default, or by iss_sub where the app supports provisioning from Okta, and sends the signed JWT as a Bearer token with JWT type global-token-revocation+jwt.

Required behaviour and responses

On a valid request the receiving server MUST revoke all active refresh tokens for the user, whether or not they were issued with offline_access, and MUST re-authenticate the user before issuing new tokens. It SHOULD invalidate access tokens but does not have to in order to report success. Okta's developer guide adds the app-side expectation that all session cookies are revoked too.

The draft also allows the authorisation server, once revocation is complete, to send a CAEP Session Revoked event over a preconfigured Shared Signals Framework stream, which reverses the usual direction of the signal and gives the caller a completion receipt.

How it relates to other revocation and logout standards

Global token revocation is one of several mechanisms, each with a different trigger, scope and guarantee. Most estates need two or three of them.

The draft's own text draws the key distinction: CAEP events are signals that a receiver may choose to ignore, whereas a global revocation request is a command. See the OAuth Token Introspection and Revocation Guide, the OpenID Connect Logout and Session Management Guide and the CAEP and Continuous Access Evaluation guide for each in depth. The OpenID Foundation's IPSIE working group lists both logout and token revocation in its initial problem space for enterprise interoperability profiles; see the IPSIE Guide.

Service identities and AI agents

The draft revokes tokens held on behalf of a user. That covers a person's sessions and also the delegated OAuth grants an AI agent or integration holds for that user, if the receiving app ties those grants to the user's subject. It does not cover credentials that belong to a workload rather than a person. Those need their own kill paths, documented in advance.

For agents, two design choices make revocation tractable. First, give each agent its own identity rather than letting it reuse a person's token, so an agent can be revoked without logging out its owner and the owner's departure revokes the agent's delegated grants. Second, prefer short-lived tokens obtained by token exchange over long-lived refresh tokens, so the kill path is "stop issuing" rather than "find every copy". See the AI Agent Kill Switch and Containment Guide, the OAuth Token Exchange and Delegation Guide and the Workload Identity Compromise Response Playbook. Where a law or contract requires an agent shutdown capability, see the AI Kill Switch Act Guide.

Integration tokens are where mass revocation is most often needed. In the Salesloft Drift breach, OAuth tokens stolen from one chatbot integration opened Salesforce tenants across hundreds of customers, and containment depended on revoking every token that integration held. The OAuth Token Theft Incident Playbook covers that response.

Deciding where to invest

• Sender or receiver: enterprises are mostly senders; they gain by enabling Universal Logout in their identity provider for apps that support it. SaaS vendors are receivers; implementing the endpoint lets enterprise customers contain account takeover in the vendor's product without a support ticket.
• Which apps first: rank by blast radius and session lifetime: email and collaboration, source control, CI/CD, cloud consoles, CRM, finance and HR. An app with a 30-day sliding session and admin data matters more than one with 15-minute sessions.
• Draft endpoint or back-channel logout: if an app already supports OIDC back-channel logout, that ends the OP-linked session on ordinary sign-out; it does not revoke refresh tokens or integration grants. Use global revocation for incidents and terminations, back-channel logout for daily sign-out.
• Apps that support neither: fall back to SCIM deactivation with a vendor-confirmed behaviour (does deactivation end sessions?), the vendor's admin API, or a manual runbook step with a named owner. Ask for global revocation support in contracts; see the Vendor contract clauses for credential revocation and breach notice.
• Small versus large organisations: a small team with one identity provider and a dozen SaaS apps can maintain a one-page revocation matrix and test it quarterly. A large estate needs the matrix in the identity governance or SOAR platform, triggered automatically from termination and high-risk detections.

Where identity fits

A revocation caller is a non-human identity with one of the most dangerous permissions in the estate: the ability to log any user out of any connected app. The draft's security considerations call it a denial-of-service vector and ask that its credential be narrowly scoped, that multi-tenant deployments use per-tenant credentials, and that the set of users a caller can revoke be limited. Treat the signing key like a privileged secret: hold it in a key management service or HSM, rotate it, and restrict which automation can use it. The draft also warns that a malicious or compromised receiving server could harvest identifiers or replay credentials, so never reuse one revocation credential across apps. See the Okta Security Hardening Guide for the identity provider side.

How to implement

1. Inventory credentials per app. For every critical app record its session lifetime, refresh token lifetime, integration grants, whether it accepts global revocation, back-channel logout, CAEP or SCIM deactivation, and the manual fallback.
2. Map identifiers. Decide which sub_id format each app understands; email breaks on renames and aliases, so prefer iss_sub or an opaque provisioned ID where available.
3. Enable for a pilot group. Turn on Universal Logout or equivalent for two or three supporting apps and a test population. Okta lets administrators set it as a response in entity risk and session protection policies or end a user's sessions from the user risk profile.
4. Test end to end. Sign a test user into each app on browser and mobile, issue the revocation, then confirm the next request with the old cookie and the old refresh token fails and the user is forced to re-authenticate. Record the time to effect.
5. Add the non-user paths. Script and test cloud role session revocation, key deactivation and agent grant revocation, and record who can run each.
6. Wire triggers. Connect termination events from HR, high-risk detections and the incident runbook to the revocation workflow. Keep a human approval step for bulk actions.
7. Plan rollback. Revocation is not reversible: the user re-authenticates. The rollback for a mistaken revocation is communication and fast re-enrolment, so test the help desk path, and make sure the break-glass accounts are excluded from automated bulk revocation. See the Break-Glass Account Guide.

Detection and measurement

• Log on the sender: every revocation request with target, app, caller, trigger and HTTP status; non-204 responses raise a ticket.
• Log on the receiver: every global revocation received, tokens and sessions revoked, and any authentication failure on the endpoint.
• Alert: bulk revocations above a threshold, revocation requests from an unexpected caller or key, repeated 401 responses (key or clock problems) and any successful use of a token issued before a revocation time, which means the app ignored the call.

Framework mapping

Common failure patterns

• Treating disable as logout: the leaver runbook disables the IdP account and closes the ticket while SaaS sessions and integration grants keep working. See the Leaver Retained Access Incident Playbook.
• Trusting the 204: success means revocation began, and access tokens may live on; without a verification step nobody notices an app that ignores the call.
• Email as the only identifier: renamed users, aliases and guest accounts return 404 and silently keep their sessions.
• Forgetting machines: a compromised user is revoked but the cloud role sessions and personal access tokens taken from their laptop are not. The Bybit hack turned on a developer's AWS session tokens.
• One shared revocation key: a single credential that can revoke any user in any app, held in a workflow tool with broad access, becomes a workforce-wide outage switch.
• Never testing: the matrix says "supported" but the first real test happens mid-incident, when the receiving endpoint has drifted or its key has expired.

Practitioner checklist

• Revocation matrix for every critical app: session and refresh lifetimes, supported mechanism, identifier format, fallback and owner.
• Universal Logout or global revocation enabled for every supporting app, with an agreed identifier mapping.
• Termination and high-risk detections trigger revocation automatically; bulk actions need approval.
• Revocation verified by app logs or CAEP completion events, not by the HTTP status alone.
• Scripted, tested kill paths for cloud role sessions, access keys, personal access tokens and agent grants.
• Revocation signing keys per tenant and per app, held in a KMS or HSM, rotated and monitored.
• Alerts on bulk revocation, unexpected callers and post-revocation token reuse.
• Quarterly end-to-end test on browser and mobile with time-to-effect recorded.
• Vendor contracts ask for global revocation or an equivalent admin API.

Standards and references

• IETF: Global Token Revocation (draft-parecki-oauth-global-token-revocation)
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• OpenID Foundation: OpenID Continuous Access Evaluation Profile 1.0
• OpenID Foundation: OpenID Connect Back-Channel Logout 1.0
• Okta Developer: Universal Logout overview
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• AWS: Revoke IAM role temporary security credentials
• GitHub Docs: REST API endpoints for revocation

Related NHI Mgmt Group resources: Session Token Theft Response Playbook · Shared Signals Framework Guide · Employee Offboarding Security Guide · NHI Offboarding and Decommissioning Guide