JWT Validation

The foundational check that confirms the token's integrity and origin. The server recomputes the signature using the header's declared algorithm and the secret key or public key, then compares it to the token's signature. A mismatch indicates tampering or a man-in-the-middle attack. Supported algorithms include:

• HS256: HMAC with SHA-256, using a shared symmetric secret
• RS256: RSA signature with SHA-256, using a private/public key pair
• ES256: ECDSA using P-256 curve and SHA-256
• EdDSA: Edwards-curve Digital Signature Algorithm for high-performance validation

A critical security control that explicitly restricts which signing algorithms the server will accept. The server must ignore the alg header from the token and use only its own configured list. This prevents algorithm confusion attacks, where an attacker changes the header to none or switches from an asymmetric algorithm (RS256) to a symmetric one (HS256), potentially allowing signature forgery using the public key as the HMAC secret.

The industry-standard protocol for delegated authorization, often confused with JWT. OAuth 2.0 defines how a client obtains an access token (frequently a JWT) to act on behalf of a resource owner. Validation involves verifying the token's issuer (iss), audience (aud), and scopes (scp) claims against the authorization server's configuration. Unlike OpenID Connect, OAuth 2.0 alone does not provide identity; it grants access. Key grant types include:

• Authorization Code with PKCE for public clients
• Client Credentials for machine-to-machine communication
• Device Authorization for input-constrained devices

An identity layer built on top of OAuth 2.0 that standardizes user authentication. OIDC introduces the ID Token, a JWT containing verified claims about the authenticated user. Validation requires checking the nonce claim to prevent replay attacks, verifying the auth_time for session age, and confirming the at_hash matches the access token. The OIDC Discovery endpoint (/.well-known/openid-configuration) provides the JSON Web Key Set (JWKS) URI for dynamic key retrieval, eliminating hardcoded public keys.

A bidirectional cryptographic protocol where both client and server present X.509 certificates during the TLS handshake. In zero-trust networking, mTLS provides transport-layer identity that complements JWT validation. The validated certificate's Subject Alternative Name (SAN) or SPIFFE ID can be bound to JWT claims to enforce that a token can only be used by the specific workload that requested it. This prevents token replay from a compromised but unauthorized host.

The Secure Production Identity Framework for Everyone defines a universal workload identity standard. A SPIFFE ID (e.g., spiffe://acme.com/payments-service) is embedded in an X.509 SVID or a JWT SVID. When validating a JWT SVID, the verifier must confirm:

• The token's sub claim matches the expected SPIFFE ID
• The signature chains to a trusted SPIFFE trust domain
• The token has not expired and includes a valid aud claim This binds the JWT to a cryptographically attested software process, not just a user.

A standardized JSON document published by an authorization server containing the public keys used to verify JWT signatures. The JWKS endpoint (commonly at /oauth2/jwks) lists keys with attributes like kty (key type), kid (key ID), and alg (algorithm). During validation, the kid header in the JWT is matched to a key in the JWKS. Key rotation is handled by periodically fetching the JWKS and caching it with a TTL. Failure to validate the kid match is a common vulnerability leading to key confusion attacks.

The network component that intercepts every request and enforces access decisions. In a JWT-based zero-trust architecture, the PEP extracts the token from the Authorization: Bearer header, performs initial structural validation (well-formedness, expiry, signature), and forwards the validated claims to the Policy Decision Point (PDP). The PEP must handle token extraction failures gracefully, returning HTTP 401 Unauthorized with a WWW-Authenticate challenge header. It never makes authorization decisions independently.