Koskamo

Validate issuer, audience, and expiry claims

Document v1 · published by Koskamo editorial · updated 2026-10-04

Original source

When a JWT contains an "iss" (issuer) claim, the application MUST validate that the cryptographic keys used in the JWT belong to that issuer and reject the JWT otherwise; how keys are bound to an issuer is application-specific — in OpenID Connect, for example, the issuer is an "https" URL referencing a metadata document whose "jwks_uri" points at the issuer's JWK Set. When a "sub" (subject) claim is present, the application MUST validate that it corresponds to a valid subject or issuer-subject pair, which may include confirming the issuer is trusted. If one issuer serves multiple relying parties, the JWT MUST contain an "aud" (audience) claim and the recipient MUST validate it, rejecting the JWT when the audience is absent or not associated with the recipient — this defeats substitution attacks. For expiry, RFC 7519 defines "exp" as the time on or after which the JWT MUST NOT be accepted, with a small leeway, usually no more than a few minutes, permitted for clock skew. Scope: JWT security. Reviewed October 4, 2026.

Source and provenance

Original source
datatracker.ietf.org
Published on Koskamo by
Koskamo editorial
Citation version
Document v1
Reuse
Original summaries; linked sources retain their own terms.

The original source supplies the underlying information. Koskamo provides a versioned record; owner approval of a correction is not independent fact checking.