JWT Validation, Signing Keys and Token Purpose

Parse is not validate

A JWT can be decoded without a key. Trust begins only after validation against a configured issuer and purpose.

Validate every applicable property:

• Signature using a key belonging to the trusted issuer.
• Explicit allowlist of acceptable algorithms.
• Exact issuer match.
• Audience for this API.
• Expiration and not-before with deliberate, small clock skew.
• Token type or purpose so an ID token is never treated as an API access token.
• Claims required by local authorization policy.

Algorithm and key confusion

Do not let an attacker-controlled alg header choose an unexpected validation path. Bind keys to intended algorithms and reject unsigned tokens. Separate validation rules for access tokens, ID tokens, password-reset tokens and logout messages.

Key rotation

An identity provider can publish current signing keys through trusted metadata. Resource servers should cache metadata for bounded periods, refresh when a previously unknown key identifier appears, and fail closed for keys that remain untrusted.

A safe rotation overlaps old and new public keys long enough for already-issued tokens and cache windows, then removes the retired key. Monitor refresh failures so fail-closed behavior does not become an invisible global outage.

ASP.NET Core answer

Configure a trusted authority, the expected API audience and explicit token validation parameters. Authentication creates the principal; policies and handlers still authorize the action and resource.

Negative tests

Test a valid signature with the wrong audience, a token from the wrong issuer, an expired token, an ID token sent to the API, an unknown signing key and a token missing the required permission. Positive-only token tests leave the dangerous branches unexamined.