Compare opaque introspected tokens with self-contained JWTs for a resource server. What are the trade-offs, and when would you pick each?

## Two validation models | Concern | Self-contained **JWT** (`.jwt()`) | **Opaque** token (`.opaqueToken()`) | |---|---|---| | Validation | **Local**: verify signature with the AS's public key (fetched once from JWK Set), check `exp`/`iss`/`aud` | **Remote**: `POST` to RFC 7662 introspection endpoint every request | | Network per request | **None** (JWKs cached) | **One round-trip** unless cached | | AS availability coupling | Loose — works if AS is down (keys cached) | Tight — AS down ⇒ can't validate ⇒ 401/503 | | Revocation | **Hard** — valid until `exp`; need denylist or very short TTL | **Instant** — AS reports `active:false` immediately | | Confidentiality of claims | Payload is base64 (not encrypted) — **readable by anyone** | Token is opaque — **claims never leave the AS** | | Token size on the wire | Larger (carries all claims) | Small (a random handle) | | Changing claims/authorities | Requires re-issue + cross-service coordination | Change centrally; introspection reflects it next call | | Scaling | Excellent — pure CPU, horizontal | Bounded by introspection endpoint throughput | ## Why JWTs can't be easily revoked A JWT is a bearer credential that is trusted purely because its signature verifies and it hasn't expired. Once issued, the resource server never consults the AS, so a logout / compromised-token event can't be honored until `exp`. Mitigations — short lifetimes plus refresh tokens, or a shared revocation/denylist — reintroduce state and, in the denylist case, a per-request lookup that erases much of the JWT latency advantage. ## Why opaque tokens cost latency Every protected request triggers `introspect(token)` → HTTP call → JSON parse. Under load this makes the introspection endpoint a **bottleneck and a single point of failure**. Standard mitigation: **cache introspection results** keyed by the token, bounded by the token's `exp`. Caching trades a little revocation immediacy (up to the cache TTL) for large latency/throughput gains — a tunable knob between the two models. ## Confidentiality & PII Because a JWT's payload is only base64url-encoded, any party (including the browser or a proxy) can read `sub`, roles, email, etc. If tokens must not leak claims, opaque tokens keep everything server-side. ## Decision guide - **Prefer JWT** when: high request volume, latency-sensitive APIs, many independently-deployed resource servers, tolerance for token lifetime as the revocation window, and no sensitive claims in the payload. - **Prefer opaque** when: you need **immediate revocation** (banking, admin sessions), tokens carry confidential data, or you want the AS to remain the single authority on every call — and the introspection latency/coupling is acceptable (often softened by caching). - **Hybrid patterns**: short-lived JWTs + refresh (approximate revocation), or JWT at the edge with introspection only for high-value operations. ## Spring specifics The two are configured on different builder paths — `oauth2ResourceServer().jwt()` vs `.opaqueToken()`. They are not interchangeable at runtime for the same request unless you wire an `AuthenticationManagerResolver` to pick per token. Both ultimately populate an `Authentication` in the `SecurityContext` (`JwtAuthenticationToken` vs `BearerTokenAuthentication`).