2026-09-30 · 6 min read · Rahul Chitturi
- oauth
- tokens
- security
RFC 7662 introspection asks an authorization server whether a token is active. The caller authenticates as the resource server or another registered client, posts the token, and reads a JSON body. active set to false means the server will not honor that token now.
A 200 response with active false is not the same failure as an HTTP 401 from your API. The first says the authorization server rejected the token. The second may mean your API rejected the caller, the audience, or a cached decision.
Separate caller authentication from the token
Record the introspection URL, how the resource server authenticated, the HTTP status, and the active value. Redact the token itself. Sending the user's access token as the only Authorization bearer, with no resource-server credential, is a common way to get active false or invalid_client.
- Confirm the resource server credential out of band.
- Treat token_type_hint as optional advice.
- Expect extra claims to be absent when active is false.
- Verify iss, aud, exp, and token type when active is true.
Check cache, expiry, and revocation
A cached active true decision must not outlive exp, and it will miss a revocation until the cache entry ends. A long-lived active false entry can reject a newly issued token if the cache key was too coarse.
Local JWT validation and introspection answer different questions. A signature check does not know about revocation. An introspection response does not replace audience and issuer checks at the resource server.
Reproduce with synthetic tokens only
Use Flashman's JWT decoder on synthetic access tokens, the JSON formatter for introspection bodies, the timestamp converter for exp and cache age, and the URL parser for the introspection endpoint.
Test a live token, an expired token, a revoked token, the wrong resource-server credential, a token issued for another API, and a stale cache entry. Keep production tokens out of logs and browser tools.