JWS (JWT) vs Opaque Token

Signed JWT / JWS

Pros

  • Self-contained claims verifiable at the edge
  • No introspection round-trip on every request
  • Works well for service-to-service authorization
  • Broad library support and debugging tooling

Cons

  • Harder to revoke instantly without extra state
  • Claims are readable unless encrypted (JWE)
  • Token size grows with claims and keys

Opaque reference token

Pros

  • Easy immediate revocation server-side
  • No readable claims on the client string
  • Keeps authorization data centralized
  • Familiar OAuth access-token pattern for browsers

Cons

  • Requires datastore or introspection calls
  • Availability of the auth server becomes critical
  • Less convenient for pure edge verification

Verdict

Use signed JWTs when services must authorize offline with public keys or shared secrets and you accept expiry-based revocation windows. Use opaque tokens when instant revoke, smaller public strings, or hiding claims from clients matters more than pure edge verification. Many mature systems mix both: opaque tokens for public clients and JWTs between internal services. Do not treat JWT as mandatory for every OAuth access token — choose the format that matches your revocation, privacy, and introspection budget. Document the choice so frontend, gateway, and service teams do not invent incompatible assumptions about what the access token string contains.

Algorithm Guides

Related Tools

Deeper Reading

Frequently Asked Questions

Is an opaque token a JWT?

No. Opaque tokens are random references without embedded verifiable claims. JWTs are self-contained signed (or encrypted) objects that verifiers can check without a session store lookup.

Can I revoke a JWT instantly?

Not without extra infrastructure such as denylists, short lifetimes plus refresh, or moving to opaque tokens with server state. Plan revocation before you ship long-lived JWT access tokens.

Which should SPAs use?

Follow your OAuth provider guidance. Many prefer opaque or carefully handled tokens with secure browser storage patterns rather than long-lived JWTs in localStorage that are easy to exfiltrate via XSS.

Can I use both formats at once?

Yes. A common pattern issues opaque access tokens to browsers while internal services exchange short-lived JWTs. Keep validation rules and storage models documented per token type.