Why architecture matters here
The architectural crux is that a JWT moves trust from a session store to a signature, and a signature only means something if you verify it against a key you chose, using an algorithm you pinned. The header field that names the algorithm is part of the attacker-controlled token; treating it as an instruction rather than a claim is the root of the two most famous JWT attacks. Pinning the expected algorithm server-side — 'this issuer signs with RS256, and I will verify with RS256, full stop' — removes the attacker's ability to choose how their token is checked. This is the first and most important line of defense, and it lives in your configuration, not the token.
The 'alg: none' and RS256-to-HS256 confusion attacks both exploit the same weakness: a validator that lets the token dictate the verification. With 'none', a naive library accepts an unsigned token as valid. With the confusion attack, an attacker takes an asymmetric setup where the server holds a public RSA key, flips the header to HS256 (an HMAC algorithm), and signs the token using that public key as the HMAC secret — because the public key is, by definition, public. A validator that hard-codes the algorithm and key type never even considers these tokens. The defense is not detecting the attack; it is making the attack unrepresentable by refusing to negotiate.
Claims are the second half of validation, and they are what turn 'this token has a valid signature' into 'this token grants this request.' A valid signature only proves the token was issued by the holder of the signing key; it says nothing about whether the token is for you, whether it is still valid, or who issued it. The iss (issuer), aud (audience), exp (expiry), and nbf (not-before) claims each close a specific hole, and skipping any one of them is a specific, exploitable gap. Signature verification and claim validation are two necessary halves; neither is sufficient alone.
Key management is the operational spine that makes signature verification work over time. Issuers rotate signing keys, so the verifier cannot hard-code a single public key; it must fetch the issuer's current keys, typically from a JWKS (JSON Web Key Set) endpoint, select the right key by the token's kid (key id) header, and cache the set with sane refresh so rotation does not cause an outage and a compromised key can be retired quickly. This introduces a live dependency and a cache-invalidation problem that must be designed rather than assumed, because a stale JWKS cache can both reject valid tokens and keep trusting a revoked key.
Revocation is the dilemma the stateless design creates. The whole point of a JWT is that you do not consult a store to verify it — but that means you also cannot easily revoke it before it expires. A stolen token is valid until exp, and if your tokens live for hours that is a large window. The architectural answers — short lifetimes with refresh tokens, a denylist keyed by jti, a per-user token version bumped on logout or compromise — each trade some statelessness back for control, and choosing among them is a deliberate design decision about how fast you must be able to cut off access.
The architecture: every piece explained
Algorithm pinning and signature verification is the cryptographic core. The validator is configured with the exact algorithm(s) it will accept for a given issuer and ignores the token's advertised alg as anything more than a cross-check that must match the pin. It then verifies the signature over the header-and-payload using the issuer's key. Only a token whose signature verifies under the pinned algorithm and the correct key proceeds; everything else is rejected before any claim is even read.
The JWKS / key store supplies the verification key. For asymmetric signing (the common, recommended case), the verifier fetches the issuer's public keys from its JWKS endpoint, indexed by kid. The key set is cached to avoid a network call per request, with a refresh policy that balances rotation responsiveness against load: refresh on a schedule, on an unknown kid, and support fast invalidation so a compromised key can be dropped. This component is a live dependency with its own availability and caching semantics.
The claim validator enforces the standard registered claims. It checks iss against the expected issuer, aud against this service's identifier so a token minted for another audience is rejected, exp so expired tokens fail, and nbf/iat so tokens are not used before they are valid — all with a small, bounded clock-skew tolerance because server clocks drift. These checks are cheap, mandatory, and each maps to a concrete attack it prevents.
The authorization layer reads scope and role claims to decide what the authenticated principal may actually do. Authentication (who you are) and authorization (what you may do) are distinct: a perfectly valid token still must be checked against the permissions the endpoint requires. Scopes, roles, or entitlement claims are validated here, and — importantly — sensitive authorization decisions should not blindly trust claims that a compromised or over-permissive issuer could inflate; high-value operations often re-check against a source of truth.
The revocation check is the optional-but-often-necessary component that reintroduces just enough state to cut off tokens early. Depending on the strategy, it consults a jti denylist, compares a token-version claim against the user's current version, or relies purely on short TTLs plus refresh-token revocation. Together these components form a pipeline where a token must pass every stage — signature, key, claims, scope, revocation — to establish a principal, as the diagram shows. A failure at any stage is a rejection, never a downgrade to partial trust.
End-to-end flow
A request arrives carrying a token, typically in an Authorization: Bearer header. The validator first parses the three segments and reads the header to obtain the kid and the advertised algorithm. It does not yet trust anything; it has only decoded structure. If the token is malformed — wrong number of segments, invalid base64url — it is rejected immediately with a 401.
The validator selects the verification key by kid from its cached JWKS, fetching a fresh key set if the kid is unknown (which can legitimately happen right after a rotation). It then verifies the signature using the pinned algorithm — not the one the header requested — over the header-and-payload bytes. A token whose header advertised an unexpected algorithm, or whose signature does not verify, dies here. This step guarantees the token was issued by the holder of the signing key and has not been tampered with.
With integrity established, the validator checks claims. It confirms iss is the expected issuer, aud includes this service, exp is in the future and nbf/iat are in the past — each within a small clock-skew allowance. Any failed claim rejects the request. This is the step that ensures a cryptographically valid token is also the right token: issued by the authority you trust, minted for you, and currently within its validity window.
Next the request passes through authorization: the endpoint compares the required scope or role against the token's claims, and — for sensitive operations — may re-verify entitlements against a source of truth rather than trusting the claim alone. If a revocation strategy is in place, the validator consults it now: is this jti denylisted, or does the token's version match the user's current version? A revoked token is rejected even though its signature and claims are otherwise valid.
Only after every stage passes does the validator establish the principal — the authenticated identity and its permissions — and let the request proceed to business logic, which operates on that trusted identity rather than on raw token claims. If any stage failed, the request is rejected with a 401 (authentication) or 403 (authorization) and, ideally, an audit log entry recording which check failed and why. The token never grants partial access; it is all stages or nothing, and the same pipeline runs identically on every service that accepts tokens so the trust boundary has no weak link.