Learning outcomes
- Separate token expiry, introspection, revocation, refresh-token invalidation, and session termination.
- Define a measurable maximum time from revocation event to denied resource request.
- Select stateful and stateless status checks for each resource risk.
- Test replay, cache, partition, clock, and partial-logout behavior.
Operating objective
After an account, grant, session, client, or credential must stop, new protected requests must fail within a stated time bound. That bound is the combined effect of event detection, issuer state, access-token lifetime, validation mode, cache lifetime, policy refresh, active connections, and application behavior.
Token mechanisms have different jobs. Expiration limits future acceptance after a fixed time. RFC 7662 lets a protected resource ask an authorization server whether a token is active and retrieve its context. RFC 7009 lets a client request invalidation of a token and related grant. Refresh-token revocation blocks new access-token issuance. Session termination blocks a login session. None of these actions automatically undoes a completed application action.
Define the objective for each trigger: user logout, administrator disable, group removal, device failure, grant withdrawal, refresh-token replay, access-token theft, signing-key compromise, and client compromise.
Signals and evidence
Measure these events with correlation identifiers and safe token fingerprints:
- Source event time, such as account disable or grant revocation.
- Time the authorization server or identity system applied the change.
- Revocation request result and affected token family or session.
- Introspection responses and cache decisions at each resource server.
- Access-token issue, expiry, audience, and status without storing the credential.
- Gateway and application authorization results after the event.
- Long-lived connection creation and termination.
- Replay or rotated-refresh-token reuse detection.
For self-contained tokens, a valid signature and time do not reveal later revocation unless the resource consults state or receives an event. For opaque tokens, introspection can give current status, but cached positive results extend the acceptance window. Record this choice as a calculated bound, not as "immediate revocation."
Response and recovery
- Classify the event and identify the subject, client, grants, sessions, refresh-token families, access-token audiences, and active connections in scope.
- Disable the source authority. Revoke grants, refresh tokens, and sessions that can mint or continue authority.
- For high-risk events, update state consulted by resource servers or rotate compromised issuer keys. A signing-key rotation can invalidate many unrelated tokens and needs a controlled recovery path.
- Terminate long-lived connections when policy requires immediate denial. A connection that passed its initial check can otherwise outlive token revocation.
- Test a new request at every material audience until all deny. Measure from the source event to the last accepted request.
- Preserve decision evidence, remove leaked credentials from telemetry, and rotate related secrets.
- Restore access through a new authenticated grant or session after the cause is contained.
Test partitions explicitly. Decide whether a resource denies, accepts a cached status, or enters reduced operation when introspection is unavailable. The choice can differ by resource risk, but it must be stated and measured.
Design tradeoffs and residual risk
Short access-token lifetimes bound stateless acceptance but increase token issuance and authorization-server dependency. Introspection improves current-state control but adds latency, central availability, and privacy exposure. Cached introspection reduces that cost while extending stale acceptance. Push events reduce polling delay but require reliable delivery, ordering, replay handling, and recovery after missed events.
Logout is not one protocol action. A client session, authorization-server session, identity-provider session, refresh token, access token, and application session can remain independent. Document which layers one logout reaches.
Residual risk includes requests accepted before propagation, offline validation until expiry, untracked token copies, active streams, clock skew, unavailable status services, and actions completed before revocation. State the maximum exposure instead of claiming instantaneous control.
Pomerium boundary
Pomerium owns its configured access session and route decisions. The identity provider owns its authentication session and credential state. Upstream applications can own separate OAuth tokens and sessions. Operators must map how a disable or logout event reaches each layer and verify Pomerium behavior for the deployed identity provider and session settings.
Exercise
Create a test user with an active browser session, one API token, one refresh token, and one long-lived connection in a staging environment. Disable the user and revoke the grant. Send a protected request every second at each audience. Record the last accepted request, first denied request, introspection cache result, token expiry, and connection termination time.
Repeat while the introspection or identity dependency is unavailable. Compare the measured results with the documented bound. File a control defect for any unowned session or longer-than-stated window.
Evaluation checklist
- Does each revocation trigger map to every session, token, grant, audience, and connection it must stop?
- Is the maximum denial time calculated and verified with real requests?
- Are introspection caching and dependency-failure behavior explicit?
- Does refresh-token replay response invalidate the active token family?
- Can responders distinguish token revocation, session termination, logout, and completed actions?
Next learning unit
Revocation Latency
Measure how long a disabled identity, authenticator, session, claim, or permission can continue to authorize action.
