Mental model#
A JWT is a compact claims representation that an application profile may sign or MAC as JWS, encrypt as JWE, or explicitly leave unsecured. A signed JWT is normally readable, not encrypted. Its safety depends on accepting only the intended protection profile and strictly validating issuer, audience, algorithm, key, time, and claims - not on decoding successfully.
Mechanism and state flow#
- Accept a token only from the expected transport and credential location.
- Parse defensively and allowlist the intended cryptographic algorithm and token type.
- Resolve trusted keys for the expected issuer and verify the signature.
- Validate issuer, audience, expiry, not-before, and required subject or authorization context.
- Use short lifetimes and current resource authorization; rotate keys with overlap and rollback procedures.
Concrete example#
A resource API validates an access token
The API expects issuer A, audience orders-api, an access-token type, and a short expiry. A valid signature from issuer A for audience analytics-api is rejected, as is an ID token presented as an access token.
Architecture consequence: Treat token purpose and audience as security boundaries, not optional informational claims.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Local JWT validation | Resource servers need low-latency verification without a lookup per request. | Revocation and stale claims persist until expiry or an added deny mechanism. |
| Opaque token introspection | Central current-state checks outweigh the extra dependency. | Latency and availability depend on the introspection service. |
| Large embedded claims | Rarely; only stable necessary context belongs in the token. | Credentials grow, leak more information, and become stale. |
Failure diagnosis#
- Failure
- An API verifies the signature but ignores audience and token purpose.
- Impact
- A token issued for another service or as an identity assertion can be replayed as API authorization.
- Detection
- Negative tests show wrong-audience or wrong-type tokens are accepted.
- Mitigation
- Validate the complete token profile, including issuer, audience, algorithm, time, and purpose-specific claims.
- Trade-off
- Strict profiles require coordinated configuration and migration across issuers and consumers.
Checklist exercise#
Work the scenario before revealing your answer
- List every check before one token can authorize one endpoint.
- Separate safe stable claims from resource permissions that need current lookup.
- Design key rotation with overlapping validation, monitoring, and rollback.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Is the payload confidential?
- What distinguishes this token from an ID token?
- How does revocation work before expiry?
- What happens during key rotation or issuer outage?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.