{"dataset":{"id":"00000000-0000-0000-0000-000000000039","slug":"jwt-best-practices","name":"JWT best practices","description":"Source-linked guidance on securing JSON Web Tokens: explicit algorithm validation, issuer/audience/expiry checks, key entropy, claim contents, and token lifetimes. Scoped to JWT security per RFC 8725 and RFC 7519; not a general authentication corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Short-lived tokens with enforced expiry","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4","text":"RFC 7519 defines the temporal claims that bound a token's usable life. The \"exp\" (expiration time) claim identifies the time on or after which the JWT MUST NOT be accepted for processing: the current date/time MUST be before the expiration value, with an optional small leeway — usually no more than a few minutes — for clock skew, and the value MUST be a NumericDate. The \"nbf\" (not before) claim symmetrically rejects tokens used before their start time, and \"iat\" (issued at) records issuance time so recipients can determine the token's age; all three are OPTIONAL claims, so a token without \"exp\" never expires on its own. Always issuing \"exp\" and keeping the lifetime short — so a leaked or replayed token loses value quickly — is Koskamo editorial guidance, not an RFC mandate; the RFCs specify the validation mechanics but leave lifetime length to the application. Scope: JWT security. Reviewed October 4, 2026.","id":"jwt-best-practices:Short-lived tokens with enforced expiry","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Keep sensitive data out of JWT claims","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc7519#section-12","text":"A JWT may contain privacy-sensitive information, and when it does, RFC 7519 requires measures to prevent disclosure to unintended parties. One approach is to use an encrypted JWT and authenticate the recipient; another is to transmit JWTs containing unencrypted privacy-sensitive information only over protocols that use encryption with endpoint authentication, such as TLS. The simplest way of minimizing privacy issues, per the RFC, is omitting privacy-sensitive information from the JWT altogether. Because a signed-only JWT's claims are readable by anyone holding the token, treating claim contents as public by default is Koskamo editorial guidance consistent with that advice. RFC 8725 adds a related caution at the encryption layer: many encryption algorithms leak the plaintext length, and compression attacks are especially powerful when attacker-controlled data shares a compression space with secret data, so compression SHOULD NOT be applied before encryption. Scope: JWT security. Reviewed October 4, 2026.","id":"jwt-best-practices:Keep sensitive data out of JWT claims","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Key management and entropy","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc8725#section-3.5","text":"Applications that sign tokens with a keyed MAC algorithm such as \"HS256\" sometimes supply a weak symmetric key with insufficient entropy, such as a human-memorable password; once an attacker obtains such a token, those keys fall to offline brute-force or dictionary attacks. RFC 8725 requires following the Key Entropy and Random Values advice in RFC 7515 Section 10.1 and the Password Considerations in RFC 7518 Section 8.8. In particular, human-memorizable passwords MUST NOT be used directly as the key to a keyed-MAC algorithm such as \"HS256\", and passwords should only be used for key encryption rather than content encryption — even then, password-based encryption remains subject to brute-force attacks. Two further key-discipline rules: each key MUST be used with exactly one algorithm, checked at operation time, and using different keys for different kinds of JWTs is a recognized substitution defense, because keys validating one kind of JWT fail to validate the others. Scope: JWT security. Reviewed October 4, 2026.","id":"jwt-best-practices:Key management and entropy","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Validate issuer, audience, and expiry claims","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc8725#section-3.8","text":"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.","id":"jwt-best-practices:Validate issuer, audience, and expiry claims","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Pin algorithms to defeat algorithm confusion","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc8725#section-3.1","text":"Signed JWTs carry the signing algorithm in the \"alg\" Header Parameter to enable cryptographic agility, but flaws in some libraries turned this into attacks: an attacker can change the algorithm to \"none\" and some libraries would \"validate\" the JWT without checking any signature, or change \"RS256\" (RSA, 2048 bit) into \"HS256\" (HMAC, SHA-256) so the library verifies an HMAC using the RSA public key as the shared secret (CVE-2015-9235). RFC 8725 mitigations: libraries MUST let the caller specify a supported set of algorithms and MUST NOT use any others; the \"alg\" or \"enc\" header MUST specify the same algorithm used for the cryptographic operation; and each key MUST be used with exactly one algorithm, checked when the operation is performed. The \"none\" algorithm should only be used when the JWT is cryptographically protected by other means, such as TLS, and libraries SHOULD NOT generate or consume \"none\" JWTs unless the caller explicitly requests it. Scope: JWT security. Reviewed October 4, 2026.","id":"jwt-best-practices:Pin algorithms to defeat algorithm confusion","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}