Compare a self-contained signed token, such as a JWT whose claims the API validates locally, with an opaque token that the API must resolve by calling an introspection or lookup service. What does each cost at request time?
answer
- Local verify vs remote resolve
- Snapshot until expiry vs always current
- Signed is not encrypted
- Pin the algorithm; check issuer, audience, expiry
- Hybrid: minutes-long access + revocable refresh
basics
~20 sA self-contained token carries its claims and a signature, so the API validates it locally with no lookup: fast and dependency-free, but the claims are a snapshot valid until expiry. An opaque token is a random string the API must resolve remotely: always current and instantly revocable, at the cost of a call on every request.
solid answer
~50 s**Self-contained (JWT-style)**: identity, expiry and claims travel in the token, signed by the issuer. Any instance verifies the signature with a public key it already holds and reads the claims - no network call, no shared state, trivially scalable. Costs: the token is larger and repeats on every request; claims are frozen at issue time, so a role revoked centrally still applies until expiry; the payload is readable by anyone holding it unless encrypted; and key rotation plus algorithm validation must be handled correctly. **Opaque**: the token is a random identifier with no meaning. The API resolves it against the issuer or a shared store, so state is always current and revocation is immediate. Costs: a lookup on the hot path of every request, a hard dependency on that service, and a decision about what to do when it is unavailable. The usual compromise is a short-lived self-contained access token plus a longer-lived revocable refresh credential, so revocation lands within one short lifetime without a per-request lookup.
code
http · 11 linesPOST /oauth2/introspect HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <resource-server-credentials>
token=8f4c1b2ad9e7
HTTP/1.1 200 OK
Content-Type: application/json
{"active":true,"sub":"user-42","scope":"orders:read","exp":1767225600}go deeper
Say that a self-contained token carries its own claims so the API checks a signature locally, while an opaque token must be looked up somewhere.
Add the consequences: no lookup and a stale window versus a per-request round trip and immediate revocation, plus short lifetimes as the usual compromise.
Cover key rotation, algorithm pinning, issuer and audience validation, introspection caching and failure behaviour, and describe the hybrid split explicitly.
Decide a platform token strategy across services and regions, quantifying the acceptable revocation window and the availability coupling each option creates.
## Two answers to "who is this caller?" **Self-contained token.** The credential *is* the assertion. A JWT is three base64url segments - header, claims payload, signature - carrying at minimum a subject, an issuer, an expiry, and often roles, scopes or a tenant. The API verifies the signature using the issuer's public key (fetched once and cached, typically from a published key set) and then trusts the claims. Verification is local CPU work: no database, no network, no shared state. **Opaque token.** The credential is a high-entropy random string that means nothing by itself. The API resolves it - by querying the authorisation server's introspection endpoint or by reading a shared session store - to learn who the caller is and whether the token is still valid. ## Request-time cost Self-contained: signature verification per request. Sub-millisecond for typical algorithms, scaling linearly with CPU. Larger headers on every request, which matters for chatty APIs and mobile clients. Opaque: a network round trip per request unless cached. Caching the introspection result reintroduces the freshness problem you chose opaque tokens to avoid, in proportion to the cache lifetime. So the honest framing is: opaque tokens trade latency and a dependency for currency, and any caching moves them back along that spectrum. ## Freshness and revocation This is the real dividing line. A self-contained token is a **snapshot**. If a user is disabled, a role removed, or a tenant suspended, the token continues to assert the old facts until it expires. Making that acceptable requires either short lifetimes, so the stale window is bounded, or an extra revocation check - a denylist of revoked token identifiers, or a per-user token version - which reintroduces a lookup, though a much cheaper one, since the list stays small and can be replicated to each instance. An opaque token has no such window: delete the record and the next request fails. ## Other differences worth naming **Confidentiality.** JWT claims are signed, not encrypted, so anyone holding the token can read them. Do not place sensitive data in claims unless you use encrypted tokens. **Size.** Tokens with many claims can exceed comfortable header limits, and they are re-sent on every request; some proxies impose header size caps. **Validation correctness.** Self-contained tokens shift security into your verification code, and the classic mistakes are real: accepting an algorithm of none, letting the token choose the algorithm so a public key is used as an HMAC secret, skipping expiry, and not checking issuer and audience. Pin the expected algorithm and validate issuer, audience and expiry. **Coupling.** Self-contained tokens let a resource server operate with no runtime dependency on the issuer beyond key material - valuable across teams, networks and regions. Opaque tokens keep the issuer authoritative at all times, which is easier to reason about for audit and immediate control. **Failure behaviour.** With opaque tokens you must decide what happens when introspection is down: fail closed, so an authorisation outage becomes a full outage, or serve from cache, extending the revocation window. Self-contained tokens simply keep working, which is a benefit and a risk in the same breath. ## Choosing Self-contained fits high-volume, multi-service, multi-region systems where a per-request lookup is unaffordable and a bounded staleness window is acceptable. Opaque fits systems where immediate revocation or central auditing is a requirement, call volume is moderate, and the introspection service is close and reliable. The widely used hybrid keeps a self-contained access token with a lifetime of minutes for the hot path, and a long-lived opaque refresh credential recorded server-side. Ordinary API calls need no lookup; the revocation window is one short lifetime; and the store is touched only on refresh. ## Interview framing Lead with local validation versus remote resolution, then the snapshot-versus-current consequence, then say the compromise out loud - short lifetimes plus a revocable refresh credential - and mention the two validation pitfalls (algorithm confusion, unchecked audience and expiry) to show you have implemented this rather than only read about it.
- How do you revoke a self-contained token before it expires?Keep lifetimes short so expiry itself bounds the exposure, and revoke at the refresh step where a server-side record already exists. If faster is required, maintain a denylist of revoked token identifiers, or a per-user token version compared against a stored value; both stay small because entries can be discarded once the token would have expired, and both can be replicated to each instance to avoid a hot-path network call.
- What are the classic validation mistakes when accepting JWTs?Trusting the token's own algorithm header, which enables the none algorithm and public-key-as-HMAC-secret confusion; not verifying expiry and not-before; and not checking issuer and audience, so a token minted for another service or tenant is accepted. Pin the expected algorithm and key source in configuration and validate issuer, audience and expiry explicitly, rejecting anything that does not match.
saying these in an interview costs you the question
- Calling JWT claims encrypted or safe for secrets when they are only signed
- Trusting the algorithm header from the token instead of pinning the expected algorithm
- Claiming self-contained tokens can never be revoked, rather than that revocation is delayed and needs extra machinery
- Introspecting on every request with a long cache lifetime while still claiming immediate revocation
- Using long-lived self-contained access tokens measured in days with no revocation path