Opaque Token Introspection and Token Exchange
Validate opaque tokens through introspection and propagate identity with token exchange.
Why Opaque Tokens Need Introspection
A JWT carries its claims inside the token, so a resource server can validate it offline by checking the signature. An opaque token is just a random reference string — it contains no claims and no signature you can verify.
- To learn who the token belongs to and whether it is still valid, the resource server must ask the authorization server.
- That call is the OAuth2 Token Introspection endpoint, defined by
RFC 7662. - The authorization server replies with
active: true/falseplus claims likesub,scope, andexp.
Opaque tokens trade offline speed for instant revocation: revoke at the AS and the very next introspection returns active: false.
The Introspection Response
Per RFC 7662, the introspection endpoint accepts the token as a form parameter and returns a JSON document. The single mandatory field is active.
A typical successful response looks like the JSON below. If the token is unknown, expired, or revoked, the server returns simply {"active": false} and Spring rejects the request.
{
"active": true,
"sub": "user-123",
"scope": "orders:read orders:write",
"client_id": "web-app",
"username": "alice",
"token_type": "Bearer",
"exp": 1735689600,
"iat": 1735686000
}All lessons in this course
- Resource Server JWT Validation and Claims
- OAuth2 Client and Authorization Code Flow
- Method Security with SpEL and Custom Voters
- Opaque Token Introspection and Token Exchange