JWT security: validation rules beyond decoding a token

Define which token the service accepts

Write down the issuer, intended audience, token purpose, signing scheme, required claims, and timing rules for each receiving service. An ID token used by a login client and an access token intended for an API are not interchangeable merely because both use JWT formatting.

Use a maintained verification library with explicit configuration for the application. The IETF’s JWT best-current-practice guidance addresses validation, algorithm confusion, key handling, and substitution risks. Avoid constructing acceptance rules from whatever values an incoming token supplies.

References: [1] IETF, [2] OWASP

Verify identity and key selection

Check the signature with the configured algorithm and trusted issuer key material. Review how key discovery, rotation, caching, and failures are handled. A key identifier is a lookup input; it should not become an unrestricted filesystem path, query, or outbound destination.

Verify issuer and audience as required by the integration and reject tokens for a different recipient or purpose. Apply timing checks with the implementation’s documented clock handling. A token that looks structurally correct can still be invalid for the service receiving it.

References: [1] IETF

Keep data and permissions separate

A commonly used signed JWT provides integrity but does not hide its claims from a holder who can decode it. Encrypted token formats have different properties. Do not put secrets or unnecessary personal data into tokens based on an assumption that a signature makes their contents private.

After validation, authorize the action against the application’s current rules. A role claim or tenant value can become stale or be too broad for a specific operation. Decide how revocation, membership removal, and sensitive permission changes affect accepted tokens and active sessions.

References: [2] OWASP, [3] OWASP, [4] OWASP

Test rejection behavior and recovery

Use safe test credentials to verify rejected cases: wrong audience, unexpected issuer, expired token, wrong token purpose, and unsupported signing configuration. Check that errors do not disclose sensitive validation internals or accidentally fall back to an unauthenticated path.

Exercise legitimate key rotation and provider failure in a controlled environment. A secure integration needs to remain predictable during operational changes without disabling verification. Record the expected failure behavior and keep acceptance tests alongside the authorization checks for sensitive API operations.

References: [1] IETF, [5] OWASP

Your next steps

1. Document the token contract for every API and authentication integration.
2. Review verification configuration, trusted keys, and token-purpose boundaries.
3. Test rejected tokens and current authorization after membership changes.
4. Book a review of your API identity and permission model.