Protocols and how-tos
JWT vs opaque access tokens: which should you use?
The real trade-off between self-contained JWT access tokens and opaque reference tokens: local validation versus immediate revocation and data exposure.
The short answer
Use JWT access tokens when many APIs must validate tokens locally without calling the authorization server; use opaque tokens with introspection when immediate revocation matters more than latency, or when token contents should not be readable by clients. Neither is more secure in itself — they move the revocation and privacy trade-off to different places.
Sources last reviewed .
What each one is
A JWT access token (RFC 9068) carries its claims and a signature. Any API holding the issuer's public key can validate it. An opaque token is a random reference; the API asks the authorization server what it means via introspection (RFC 7662).
Trade-offs
- Revocation: a JWT remains valid until exp. An opaque token can be invalidated instantly.
- Latency and availability: JWT validation is local; introspection adds a call and a dependency, mitigated by short caches.
- Privacy: JWT payloads are readable by anyone holding the token, including the client. Do not put personal data in them that the client should not see.
- Size: JWTs are larger and travel on every request.
A practical default
Short-lived JWT access tokens (minutes, not hours), opaque rotating refresh tokens, and introspection or a session check for operations where acting on a revoked session would be unacceptable. ID tokens are always JWTs, but they are for the client, not for APIs.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.