The Problem with Long Lived Tokens
A signed access token is self contained, so a resource server can validate it offline. The downside is that once issued, it stays valid until it expires, even if the user logged out or the token was stolen. Two mechanisms address this.
Introspection and Revocation
Token introspection lets a resource server ask the authorization server whether a token is currently active, returning its status, scope, and expiry. This trades a network call for an authoritative, up to date answer.
Revocation lets a client or admin explicitly invalidate a token before it expires, so a stolen or logged out token stops working.
- Use short lived access tokens to limit the window if revocation is not checked on every call.
- Pair short access tokens with longer refresh tokens that can be revoked centrally.
- For high value actions, prefer introspection so you act on current status, not stale claims.
The tension is performance versus freshness: offline validation is fast but cannot reflect a mid life revocation, while introspection is authoritative but adds latency.
Key idea
Introspection asks the authorization server whether a token is still active and revocation invalidates tokens early, trading offline speed for freshness, so short lived tokens plus revocable refresh tokens balance both.