]> Independent

yaronf.ietf@gmail.com

dick.hardt@gmail.com

Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Security Web Authorization Protocol JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE attacks Claims Security Cryptography JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore obsoletes the existing JWT BCP specification RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. About This Document Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction JSON Web Tokens, also known as JWTs , are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. The JWT specification has seen rapid adoption because it encapsulates security-relevant information in one easy-to-protect location, and because it is easy to implement using widely available tools. One application area in which JWTs are commonly used is representing authorization information, such as OAuth 2.0 access tokens , and identity information, such as OpenID Connect ID Tokens . The details of these uses are application- and deployment-specific. Since the JWT specification was published, there have been several widely published attacks on implementations and deployments. Such attacks are the result of under-specified security mechanisms, as well as incomplete implementations and incorrect usage by applications. The goal of this document is to facilitate secure implementation and deployment of JWTs. Many of the recommendations in this document are about implementation and use of the cryptographic mechanisms underlying JWTs that are defined by JSON Web Signature (JWS) , JSON Web Encryption (JWE) , and JSON Web Algorithms (JWA) . Others are about use of the JWT claims themselves. These are intended to be minimum recommendations for the use of JWTs in the vast majority of implementation and deployment scenarios. Other specifications that reference this document can have stricter requirements related to one or more aspects of the format, based on their particular circumstances; when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a floor, not a ceiling, so stronger options are always allowed (e.g., depending on differing evaluations of the importance of cryptographic strength vs. computational load). Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document. This document obsoletes . In addition to retaining the guidance from that BCP, it adds recommendations addressing attacks and vulnerabilities discovered since its publication; summarizes those additions. This document also updates by tightening claim and "typ" usage and validation (especially audience, issuer/subject, and explicit typing), and by restricting how Unsecured JWTs (alg value "none") are used.

Target Audience The intended audiences of this document are:

• Implementers of JWT libraries (and the JWS and JWE libraries used by those libraries),
• Implementers of code that uses such libraries (to the extent that some mechanisms may not be provided by libraries, or until they are), and
• Developers of specifications that rely on JWTs, both inside and outside the IETF.

Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Threats and Vulnerabilities This section lists some known and possible problems with JWT implementations and deployments. Each problem description is followed by references to one or more mitigations to those problems.

Weak Signatures and Insufficient Signature Validation Signed JSON Web Tokens carry an explicit indication of the signing algorithm, in the form of the "alg" Header Parameter, to facilitate cryptographic agility. This, in conjunction with design flaws in some libraries and applications, has led to several attacks:

• The algorithm can be changed to "none" by an attacker, and some libraries would trust this value and "validate" the JWT without checking any signature.
• An "RS256" (RSA, 2048 bit) parameter value can be changed into "HS256" (HMAC, SHA-256), and some libraries would try to validate the signature using HMAC-SHA256 and using the RSA public key as the HMAC shared secret (see and ).

For mitigations, see Sections and .

Weak Symmetric Keys In addition, some applications use a keyed Message Authentication Code (MAC) algorithm, such as "HS256", to sign tokens but supply a weak symmetric key with insufficient entropy (such as a human-memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an attacker gets hold of such a token . For mitigations, see .

Incorrect Use and Composition of Encryption and Signature Most authentication use cases only require a simple signed JWT as their token. However verifiers don't always check that the received JWT is a JWS (a signed JWT) as opposed to a JWE (a JWT with encrypted structure). This can result in vulnerabilities when the verifier's library does not distinguish between successful decryption and successful signature validation . In the more complicated use cases where confidentiality is required, some libraries that decrypt a JWE-encrypted JWT to obtain a JWS-signed object do not always validate the internal signature. For mitigations, see .

Plaintext Leakage through Analysis of Ciphertext Length Many encryption algorithms leak information about the length of the plaintext, with a varying amount of leakage depending on the algorithm and mode of operation. JWEs are vulnerable to this leakage. This problem is exacerbated when the plaintext is initially compressed, because the length of the compressed plaintext and, thus, the ciphertext depends not only on the length of the original plaintext but also on its content. Compression attacks are particularly powerful when there is attacker-controlled data in the same compression space as secret data, which is the case for some attacks on HTTPS. See for general background on compression and encryption and for a specific example of attacks on HTTP cookies. For mitigations, see .

Insecure Use of Elliptic Curve Encryption Per , several JavaScript Object Signing and Encryption (JOSE) libraries fail to validate their inputs correctly when performing elliptic curve key agreement (the "ECDH-ES" algorithm). An attacker that is able to send JWEs of its choosing that use invalid curve points and observe the cleartext outputs resulting from decryption with the invalid curve points can use this vulnerability to recover the recipient's private key. For mitigations, see .

Multiplicity of JSON Encodings Previous versions of the JSON format, such as the obsoleted , allowed several different character encodings: UTF-8, UTF-16, and UTF-32. This is not the case anymore, with the latest standard only allowing UTF-8 except for internal use within a "closed ecosystem". This ambiguity, where older implementations and those used within closed environments may generate non-standard encodings, may result in the JWT being misinterpreted by its recipient. This, in turn, could be used by a malicious sender to bypass the recipient's validation checks. For mitigations, see .

Substitution Attacks There are attacks in which one recipient will be given a JWT that was intended for it and will attempt to use it at a different recipient for which that JWT was not intended. For instance, if an OAuth 2.0 access token is legitimately presented to an OAuth 2.0 protected resource for which it is intended, that protected resource might then present that same access token to a different protected resource for which the access token is not intended, in an attempt to gain access. If such situations are not caught, this can result in the attacker gaining access to resources that it is not entitled to access. For mitigations, see Sections and .

Cross-JWT Confusion As JWTs are used by more protocols in diverse ways, it becomes increasingly important to prevent JWT tokens that have been issued for one purpose being used for another. Note that this is a specific type of substitution attack. If the JWT could be used in an application context in which it could be confused with other kinds of JWTs, then mitigations can be employed to prevent these substitution attacks. For mitigations, see Sections , , , and .

Indirect Attacks on the Server Various JWT claims are used by the recipient to perform lookup operations, such as database and Lightweight Directory Access Protocol (LDAP) searches. Others include URLs that are similarly looked up by the server. Any of these claims can be used by an attacker as vectors for injection attacks or server-side request forgery (SSRF) attacks. For mitigations, see .

Computation Cost of Unreasonable Number of Hash Iterations The p2c (PBES2 Count) header parameter for the PBES2 encryption algorithms specifies the number of iterative hash computations to be performed. Attackers can use a very large count, thereby imposing an unreasonable computational burden on recipients. For mitigations, see .

Algorithm Verification Code Not Defensively Written Some JWT implementations included a list of disallowed algorithm names, e.g., do not use "none". These same applications misinterpreted the JOSE specifications when parsing the token, reading algorithm values as if they were case-insensitive. The end result was that an attacker could change the "alg" value to "noNE" and bypass the security check. For mitigations, see .

JWE Decompression Bomb Attack JWE supports the optional compression of the plaintext prior to encryption via the "zip" header parameter as defined in Section 4.1.3. Upon decryption, recipients are expected to decompress the payload before further processing. However, if the recipient does not enforce limits on the size of the decompressed output, an attacker can craft a malicious JWE with a highly compressed, arbitrarily large payload. This can cause excessive resource consumption (CPU, memory), resulting in Denial of Service (DoS). For mitigation, see .

JWT Format Confusion Some JWS implementations support both the Compact and JSON Serializations. While JWTs must use the Compact Serialization (), if an application by mistake verifies a JWT using the JSON Serialization but extracts claims by parsing it as a JWT using the Compact Serialization (e.g., via string splitting), an attacker can craft a valid JSON JWS with a forged payload. This mismatch in format handling can lead to authentication bypass or impersonation. For mitigations, see .

Best Practices The best practices listed below should be applied by practitioners to mitigate the threats listed in the preceding section.

Perform Algorithm Verification Libraries MUST provide a mechanism that enables developers to explicitly restrict the set of algorithms permitted for use and MUST NOT employ any algorithms outside this configured set when performing cryptographic operations. The library MUST verify that the algorithm specified in the "alg" or "enc" header parameter is consistent with the algorithm associated with the key identified by the corresponding identifier (e.g., "kid") during key lookup. When a recipient receives a JWT signed by a particular issuer, it MUST determine which algorithms are permitted for itself and that issuer and ensure that the received JWT complies with those requirements. It MUST likewise validate that the algorithms used by encrypted JWTs are among those supported by the intended recipient. In accordance with established cryptographic best practices, each key MUST be used with exactly one algorithm. Compliance with this requirement MUST be enforced and validated at the time the cryptographic operation is executed. As a best practice, libraries should opt for defensive security policies to cope with potential issues in the underlying infrastructure, such as the JSON parser. In particular, libraries should use allowlists for critical parameters such as "alg" instead of blocklists, because blocklists cannot anticipate every unsafe or misspelled value an attacker might use.

Use Appropriate Algorithms As says, "it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid." Therefore, applications MUST only allow the use of cryptographically current algorithms that meet the security requirements of the application. This set will vary over time as new algorithms are introduced and existing algorithms are deprecated due to discovered cryptographic weaknesses. Applications MUST therefore be designed to enable cryptographic agility. The "none" algorithm should only be used when the JWT is cryptographically protected by other means. JWTs using "none" are often used in application contexts in which the content is optionally signed. The URL-safe claims representation and processing in this context can be the same in both the signed and unsigned cases. The "none" algorithm is deprecated by . JWT libraries MUST NOT generate JWTs using "none" unless explicitly requested to do so by the caller. Similarly, JWT libraries MUST NOT consume JWTs using "none" unless explicitly allowed by the caller. Applications SHOULD follow these algorithm-specific recommendations, because deviating from them may re-enable known attacks on the listed algorithms unless an application-specific threat analysis shows the risk is acceptable:

• Deprecate all RSA-PKCS1 v1.5 encryption algorithms (), as specified in , preferring RSAES-OAEP ().
• Elliptic Curve Digital Signature Algorithm (ECDSA) signatures require a unique random value for every message that is signed. If even just a few bits of the random value are predictable across multiple messages, then the security of the signature scheme may be compromised. In the worst case, the private key may be recoverable by an attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA using the deterministic approach defined in , unless this is not reasonably implementable. This approach is completely compatible with existing ECDSA verifiers and so can be implemented without new algorithm identifiers being required.

Readers are advised that defines fully-specified JOSE algorithm identifiers and deprecates polymorphic identifiers such as "EdDSA". New deployments SHOULD prefer fully-specified algorithm identifiers (for example, "Ed25519" rather than "EdDSA") when negotiating and configuring algorithms, unless backward compatibility requires use of the older polymorphic identifiers.

Validate All Cryptographic Operations All cryptographic operations used in the JWT MUST be validated and the entire JWT MUST be rejected if any of them fail to validate. This is true of JWTs with a single set of Header Parameters. If an implementation supports Nested JWTs, as defined in , then both the outer and inner operations MUST be validated using the keys and algorithms supplied by the application. Libraries MUST allow the recipient to distinguish between Unsecured JWTs, signed JWTs (JWSes), encrypted JWTs (JWEs), and signed and encrypted JWTs (Nested JWTs). This allows recipients to easily apply policies that only accept appropriate JWTs for the application context. Note that authentication use cases typically require the use of signed JWTs.

Validate Cryptographic Inputs Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agreement ("ECDH-ES"), take inputs that may contain invalid values. This includes points not on the specified elliptic curve or other invalid points (e.g., Section 7.1 of ). The JWS/JWE library MUST validate these inputs before using them or use underlying cryptographic libraries that do so (or both). Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) ephemeral public key (epk) inputs should be validated according to the recipient's chosen elliptic curve. For the NIST prime-order curves P-256, P-384, and P-521, validation MUST be performed according to Section 5.6.2.3.4 (ECC Partial Public-Key Validation Routine) of "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography" . If the "X25519" or "X448" algorithms are used, then the security considerations in apply.

Ensure Cryptographic Keys Have Sufficient Entropy The Key Entropy and Random Values advice in , the Password Considerations in , and PBKDF2 as specified in MUST be followed. In particular, human-memorizable passwords MUST NOT be directly used as the key to a keyed-MAC algorithm such as "HS256". Moreover, passwords should only be used to perform key encryption, rather than content encryption, as described in . Note that even when used for key encryption, password-based encryption is still subject to brute-force attacks.

Avoid Compression of Encryption Inputs Compression of data SHOULD NOT be used when creating a JWE, because such compressed data often reveals information about the plaintext, as described in , unless this risk is outside the applicable threat model.

Use UTF-8 , , and all specify that UTF-8 be used for encoding and decoding JSON used in Header Parameters and JWT Claims Sets. This is also in line with the latest JSON specification . Implementations and applications MUST do this and not use or allow the use of other Unicode encodings for these purposes.

Validate Issuer and Subject When a JWT contains an "iss" (issuer) claim, the application MUST validate that the cryptographic keys used for the cryptographic operations in the JWT belong to the issuer. If they do not, the application MUST reject the JWT. The means of determining the keys owned by an issuer is application-specific. As one example, OAuth 2.0 authorization server "issuer" values are "https" URLs that reference a JSON metadata document that contains a "jwks_uri" value that is an "https" URL from which the issuer's keys are retrieved as a JWK Set . This same mechanism is used by OpenID Connect . Other applications may use different means of binding keys to issuers. Similarly, when the JWT contains a "sub" (subject) claim, the application MUST validate that the subject value corresponds to a valid subject and/or issuer-subject pair at the application. This may include confirming that the issuer is trusted by the application. In the OAuth context, discusses the possibility of confusing user identifier and client ID values. If the issuer, subject, or the pair are invalid, the application MUST reject the JWT.

Use and Validate Audience If the same issuer can issue JWTs that are intended for use by more than one relying party or application, or may do so in the future, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker. In such cases, the relying party or application MUST validate the audience value, and if no audience value is present or none of the values are associated with the recipient, it MUST reject the JWT.

Carefully Evaluate Received Claims Treat claim values as being potentially attacker-provided input. The "kid" (key ID) header is used by the relying application to perform key lookup. Applications MUST ensure that this does not create SQL or LDAP injection vulnerabilities by validating and/or sanitizing the received value. Similarly, blindly following a "jku" (JWK set URL) or "x5u" (X.509 URL) header, which may contain an arbitrary URL, could result in server-side request forgery (SSRF) attacks. Applications SHOULD protect against such attacks, e.g., by matching the URL to an allowlist of permitted locations and ensuring no cookies are sent in the GET request, unless there are no local resources to protect (e.g., a hosted sandbox). When such an allowlist is not available, the authorization server MUST check what a hostname resolves to and avoid making a request if it resolves to a loopback or local IP address, because otherwise an attacker-chosen URL can cause the server to fetch arbitrary content from within the security domain. An example of this is when "attacker.example.com/etc/passwd" is used as the "jwks_uri" value and there is a DNS entry for "attacker.example.com" that resolves to "127.0.0.1" or other local IP address values.

Use Explicit Typing When two different uses of JWTs share a common set of claims, one kind of JWT can be confused for another. If a particular kind of JWT is subject to such confusion, that JWT can include an explicit JWT type value, and the validation rules can specify checking the type. This mechanism can prevent such confusion. Explicit JWT typing is accomplished by using the "typ" Header Parameter. For instance, the specification uses the "application/secevent+jwt" media type to perform explicit typing of Security Event Tokens (SETs). An example of an ad-hoc means of preventing confusion between different kinds of JWTs is the requirement in Logout Tokens prohibiting the inclusion of a "nonce" claim so that Logout Tokens will fail the validation rules for ID Tokens . The use of explicit typing avoids the need for employing such ad-hoc mechanisms when the validation rules for both kinds of JWTs include validating the "typ" values and the acceptable "typ" values for the two kinds of JWTs are distinct. Per , the "typ" Header Parameter declares the media type of the complete JWS. To keep header values compact, producers are RECOMMENDED to omit the "application/" prefix from "typ" when no other "/" appears in the media type, as specified in that section, unless application requirements or interoperability needs call for including the prefix; recipients using the media type value MUST treat a "typ" value with no "/" as if "application/" were prepended. When explicit typing is employed:

• Implementations SHOULD register the full media type name "application/example+jwt", where "example" identifies the specific kind of JWT.
• Implementations SHOULD set the corresponding "typ" value to "example+jwt".

These recommendations apply unless the JWT cannot be confused with other kinds of JWTs in its application context, in which case the media type and "typ" pairing MAY be omitted. Distinct types make cross-JWT substitution harder when validators check "typ". Misapplying the prefix rule in can cause validators to reject otherwise valid tokens or accept the wrong type. For example, for Security Event Tokens (SETs) , the media type is "application/secevent+jwt" and the "typ" value should be "secevent+jwt", because SETs are often issued in contexts where they could otherwise be mistaken for other kinds of JWTs. When applying explicit typing to a Nested JWT, the "typ" Header Parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set). In some cases, the same "typ" Header Parameter value will be present in the outer JWT as well, to explicitly type the entire Nested JWT. Note that the use of explicit typing may not achieve disambiguation from existing kinds of JWTs, as the validation rules for kinds of JWTs defined before the guidance on explicit typing in was available often do not use the "typ" Header Parameter value. Also, note that attempting to retrofit mandatory explicit typing into the validation rules for existing kinds of JWTs not already using it would be a breaking change; if a legacy implementation creates a JWT without the explicit type and an updated implementation receiving it requires the explicit type, the JWT will be rejected. The implementations will not interoperate. However, retrofitting a rule that if the JWT contains a "typ" value, then it MUST be the expected explicit type, is not a breaking change. Another consideration for existing kinds of JWTs is that the use of a "typ" value of "JWT", as originally recommended in , does not constitute effective explicit typing. Explicit typing is RECOMMENDED for new uses of JWTs, because without it, mutually exclusive validation rules are harder to enforce and cross-JWT confusion becomes more likely.

Use Mutually Exclusive Validation Rules for Different Kinds of JWTs Each application of JWTs defines a profile specifying the required and optional JWT claims and the validation rules associated with them. If more than one kind of JWT can be issued by the same issuer, the validation rules for those JWTs MUST be written such that they are mutually exclusive, rejecting JWTs of the wrong kind. To prevent substitution of JWTs from one context into another, application developers may employ a number of strategies:

• Use explicit typing for different kinds of JWTs. Then the distinct "typ" values can be used to differentiate between the different kinds of JWTs.
• Use different sets of required claims or different required claim values. Then the validation rules for one kind of JWT will reject those with different claims or values.
• Use different sets of required Header Parameters or different required Header Parameter values. Then the validation rules for one kind of JWT will reject those with different Header Parameters or values.
• Use different keys for different kinds of JWTs. Then the keys used to validate one kind of JWT will fail to validate other kinds of JWTs.
• Use different "aud" values for different uses of JWTs from the same issuer. Then audience validation will reject JWTs substituted into inappropriate contexts.
• Use different issuers for different kinds of JWTs. Then the distinct "iss" values can be used to segregate the different kinds of JWTs.

Given the broad diversity of JWT usage and applications, the best combination of types, required claims, values, Header Parameters, key usages, and issuers to differentiate among different kinds of JWTs will, in general, be application-specific. As discussed in , for new JWT applications, the use of explicit typing is RECOMMENDED.

Limit Hash Iteration Count Implementations are RECOMMENDED to set a reasonable upper limit on the number of hash iterations that can be performed when validating encrypted content using PBES2 encryption algorithms, so as to prevent attackers from imposing an unreasonable computational burden on recipients. As an example, recommends 600,000 iterations (at time of publishing) when using HMAC-SHA-256 in a FIPS-140 context. Rejecting inputs with a p2c (PBES2 Count) value larger than twice that figure is RECOMMENDED, unless threat analysis on the recipient side results in accepting a larger number of iterations.

Check JWT Format Type Implementations MUST confirm the JWT is in a legal format while parsing it. Legal JWTs, being dot-concatenated base64url strings, contain only the ASCII characters for letters, numbers, dash, underscore, and period. Content with any other characters - especially braces and quotation marks - is not a JWT and MUST be rejected.

Limit JWE Decompression Size Implementations are RECOMMENDED to set a reasonable upper limit on the decompressed size of a JWE such as 250 KB, because without such a limit, decompression can impose an unreasonable memory or CPU burden on recipients.

Security Considerations This entire document is about security considerations when implementing and deploying JSON Web Tokens.

IANA Considerations This document has no IANA actions.

Acknowledgements

Acknowledgements for RFC 8725 The following acknowledgements from , the text of which is incorporated into this specification, are retained. Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point attack to the attention of JWE and JWT implementers. Tim McLean published the RSA/HMAC confusion attack . Thanks to Nat Sakimura for advocating the use of explicit typing. Thanks to Neil Madden for his numerous comments, and to Carsten Bormann, Brian Campbell, Brian Carpenter, Alissa Cooper, Roman Danyliw, Ben Kaduk, Mirja Kühlewind, Barry Leiba, Dan Moore, Eric Rescorla, Adam Roach, Martin Vigoureux, and Éric Vyncke for their reviews.

Acknowledgements for [[ this specification ]] We would like to thank Brian Campbell, Deb Cooley, Jianjun Chen, Dan Moore, Aaron Parecki, Filip Skokan, Ketan Talaulikar, Tom Tervoort, Enze Wang, and Jesse Yang for their contributions to the new content in this specification.

References Normative References This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. National Institute of Standards and Technology Hazelcast This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations are expected to meet. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References American National Standards Institute Springer Berlin Heidelberg NIST National Vulnerability Database NIST National Vulnerability Database Springer Berlin Heidelberg The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. OWASP This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053.

Changes from RFC 8725 This document obsoletes RFC 8725 and provides several significant improvements and additions:

1. Algorithm Verification: Added defensive checking to address incorrect reading of alg values as being case-insensitive ( and ).
2. Encryption-Signature Confusion: Added mitigation for attacks where verifiers don't distinguish between successful decryption and successful signature validation ( and ).
3. PBES2 Count Limits: Added requirements to reject unreasonably large p2c (PBES2 Count) values to prevent DoS attacks ( and ).
4. JWT Format Confusion: Added mitigation for JWT serialization format confusion attacks ( and ).
5. Compression DoS: Added mitigation for DoS attacks resulting from abuse of compression in JWE ( and ).
6. Explicit Typing: Expanded the guidance on explicit typing by defining recommended typ and media type conventions, recipient processing rules, and deployment guidance for new and existing JWT types ( and ).
7. Untrusted Header Parameters and SSRF: Added guidance on treating kid, jku, and x5u as potentially attacker-controlled input, including SSRF mitigations and DNS resolution checks when processing untrusted URLs ().
8. Normatively references , makes the text requiring application opt-in to use JWTs with algorithm "none" a "MUST", and states that the RSA-PKCS1 v1.5 algorithms are deprecated.

Document History [[Note to RFC Editor: please remove before publication.]]

draft-ietf-oauth-rfc8725bis-08

• Clarified that Nested JWT validation applies when Nested JWTs are supported (SECDIR review).
• Applied IESG ballot comments by Ketan Talaulikar (Introduction relationships, Compact Serialization and typ prefix citations).
• Updated Appendix A (Changes from RFC 8725) with complete bullets and section references.
• Added an informative mention of fully-specified JOSE algorithm identifiers ().
• Made the reference normative and rewrote the text on "alg":"none" and RSA-PKCS1 v1.5 accordingly.
• Corrected section reference and itemized list syntax and removed extraneous spaces in the source.
• Applied spelling and grammar corrections.

draft-ietf-oauth-rfc8725bis-07

• Applied ARTART review suggestions for SHOULD language in Sections 3.1, 3.2, 3.6, and 3.10.
• Applied ARTART review suggestions regarding explicit typing (Section 3.11).

draft-ietf-oauth-rfc8725bis-06

• AD review follow-up: Promoted selected lowercase must/should guidance to normative MUST language.

draft-ietf-oauth-rfc8725bis-05

• Applied suggestions by responsible AD Deb Cooley.

draft-ietf-oauth-rfc8725bis-04

• Applied suggestions by document shepherd Hannes Tschofenig.

draft-ietf-oauth-rfc8725bis-03

• Described relationship between explicit typing and kinds of JWTs not already employing it.

draft-ietf-oauth-rfc8725bis-02

• Incorporated Aaron Parecki's review suggestions.
• Acknowledged contributors to the new content in this specification.

draft-ietf-oauth-rfc8725bis-01

• Applied editorial suggestions by Dan Moore.
• Described changes relative to RFC 8725.

draft-ietf-oauth-rfc8725bis-00

• Draft adopted, no textual changes

draft-sheffer-oauth-rfc8725bis-02

• Obsoletes RFC 8725 and updates RFC 7519.

draft-sheffer-oauth-rfc8725bis-01

• Mitigate encryption-signature confusion.
• Reject unreasonably large p2c (PBES2 Count) values.
• Defensive checking to address incorrect reading of alg values as being case-insensitive.
• Mitigate DoS attacks resulting from abuse of compression.
• Mitigate JWT serialization format confusion.

draft-sheffer-oauth-rfc8725bis-00

• Initial version, text is identical to RFC 8725.