Revocation exposure statement#

Requirement SES-023: local JWT verification cannot observe a revocation that happens after the token was issued. This page states, for each kind of consumer and each revocation event, when access actually stops. It applies to the code in this repository with default configuration.

Consumers#

Offline exposure window#

window = remaining token lifetime + verifier clock tolerance

• Access-token lifetime is set per API resource: access_token_ttl_seconds, default 300 s, range 30–3600 s, optionally shortened per client and capped by tokens.max_access_token_ttl (60 min).
• Clock tolerance: the Go SDK verifier defaults to 30 s (maximum 60 s); the server's own verifier uses tokens.clock_skew (60 s).
• Default worst case for an offline verifier: about 5.5 minutes after revocation. Longer resource lifetimes lengthen it proportionally.

Introspection checks#

For JWT access tokens: signature and key not compromised; resource registered for the caller and active; JTI not revoked; client active; user able to authenticate (or service principal active); session active if the token has sid, otherwise (offline grants) no account-wide revocation of the user's tokens at or after the token's iat (SES-005: one lookup on the token_revocations index); membership and organization active if the token has org_id. User and exchanged JWTs also require a signed grant_id whose grant is active, unexpired, in the same realm and owned by the subject. Ordinary user tokens must match its client; an exchange retains its originating grant. UserInfo and IdP user APIs enforce the same live grant rule. A missing grant link fails closed; obtain fresh tokens when upgrading an earlier development build (upgrades.md).

For opaque tokens additionally: token not revoked or expired; grant active. For support tokens: grant active and unexpired; actor and target users active; target membership and organization active; actor session active; actor still holds support.impersonation.start in the organization. For API keys and personal tokens: credential active and unexpired; owner active; owner's membership active when the credential is organization-bound.

Events#

Membership states (TEN-003)#

Address-only invitations never create an invited membership, so member lists do not reveal whether an address belongs to an existing account (DOM-008). JWT access tokens already issued remain verifiable offline until expiry; strict-online resources and introspection see the change immediately.

Caveats#

• Offline-grant JWTs have no sid. Introspection and UserInfo cannot tie them to a session, so they check the user-level revocation record instead: after "logout everywhere" (and the other account-wide revocations in the table above) they are inactive at once (SES-005, TestLogoutEverywhereEndsOfflineTokens). Revocations that keep offline grants (the surviving account of an account merge, a received shared signal that does not cover offline access) record only their sessions, so offline-grant tokens stay active until expiry, like the grants they come from. Offline verifiers still accept every unexpired token. Because iat has one-second resolution, a token issued in the same second as an account-wide revocation is treated as issued before it.
• Realm suspension does not affect introspection. Introspection keeps reporting unexpired tokens active; combine suspension with session revocation.
• authz_version in a JWT is a hint. It means something only when compared to the value introspection returns.
• Requests already authorized or in flight when a revocation commits complete (§13.2); long-running jobs or streams need their own re-checks.
• The IdP does not enforce a resource's verification_mode; bounded_online is met only if the resource uses the SDKs' bounded-state mode (or an equivalent consumer of the session-event stream) with a staleness bound it chooses.
• DPoP-bound tokens (cnf.jkt) are not enforced by the Go SDK verifier; see docs/protocols/oauth-oidc-profile.md.

Default lifetimes#