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.
Validate issuer, audience, and expiry claims
Document v1 · published by Koskamo editorial · updated 2026-10-04
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.