Validate a signed access token locally when speed matters and short lifetimes are acceptable. Call the introspection endpoint when you need to know right now whether a token is still active, or when tokens are opaque. Many APIs combine both: local checks first, introspection for sensitive actions.
Local validation
If the access token is a signed JWT, the API can verify the signature with the issuer's public keys, then check iss, aud, exp and scope without contacting anyone. It is fast, scales with no dependency on the authorization server at request time, and keeps working during short outages of that server.
The cost is staleness. A token revoked after issue still passes until it expires. A user who has been disabled keeps access until the token's lifetime ends.
Introspection
RFC 7662 defines an endpoint where a resource server posts a token and gets back a JSON answer. The key field is active. It also may return scope, client_id, username, exp, iat, nbf, sub, aud, iss and jti.
Important details from the RFC:
- The caller must authenticate, so attackers cannot scan for valid tokens.
- Use POST so tokens stay out of server logs.
- An expired, revoked, unknown or disallowed token returns only the field
activeset to false. That is a normal response, not an error. - Bad caller credentials get HTTP 401.
- The endpoint requires TLS.
Introspection works for opaque tokens too, which have no readable content for local validation.
The trade-off
| Local JWT check | Introspection | |
|---|---|---|
| Latency | None | One network call per check |
| Revocation visible | Only after expiry | Immediately |
| Works with opaque tokens | No | Yes |
| Dependency at request time | Keys only | Authorization server |
Caching without losing the benefit
Caching introspection results reduces load but opens a window where a revoked token still works. The RFC says a cached response must not outlive the token's exp. Choose a cache lifetime that matches how fast you need revocation to bite. A few seconds to a minute is common for sensitive APIs, though the right number is your call.
A practical pattern
- Validate the JWT locally on every request: signature, issuer, audience, expiry.
- For high risk operations such as changing payment details or deleting data, also introspect.
- Keep access tokens short lived, and rely on refresh tokens for longer sessions.
- Return 401 for inactive tokens and 403 for valid tokens that lack scope.
Things to avoid
- Skipping the audience check because introspection said
active. Confirm the token was meant for your API. - Sending introspection requests without authentication.
- Treating a network failure to the introspection endpoint as success. Fail closed for sensitive actions.
Quick check
Does introspection replace signature verification?
It can, because the authorization server checks the token itself. If you validate locally instead, you must verify the signature and claims yourself.
How short should access tokens be if I validate locally?
The spec does not set a number. Pick a lifetime that limits the damage of a leaked token while keeping refresh traffic reasonable, and add introspection for the riskiest actions.
Sources
Last reviewed: 19 October 2026.
