I support the idea of this document overall. Here are some notes from my review:
> One application area in which JWTs are commonly used is representing digital > identity information, such as OpenID Connect ID Tokens [OpenID.Core] and > OAuth 2.0 [RFC6749] access tokens and refresh tokens Change to "representing authorization or identity information, such as OAuth 2.0 access tokens [RFC9068] and OpenID Connect ID Tokens [OpenID.Core]" It is not common practice to use JWTs for refresh tokens, since refresh tokens are only consumed by the issuer, whereas access tokens are consumed by the resource server which is a separate role from the authorization server that issues them. Also updated the reference to the JWT access token spec. > if a JWT is cryptographically protected end-to-end by a transport layer, such > as TLS using cryptographically current algorithms, there may be no need to > apply another layer of cryptographic protections to the JWT. In such cases, > the use of the "none" algorithm can be perfectly acceptable. This makes it sound like it's acceptable to send alg none JWTs as access tokens over TLS, which is obviously not true. I would suggest removing all references to alg none being acceptable. If there is an actual concrete use case for alg none JWTs, list it out explicitly, preferably to a reference of a spec/profile that uses it. Section 3.3 mentions the term "Nested JWT" capitalized, but this is the first occurrence of the term in the document. Add a reference to where Nested JWT is defined, or change to lowercase if the intent is to mention the general concept of nested JWTs. > The means of determining the keys owned by an issuer is application-specific. > As one example, OpenID Connect [OpenID.Core] 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 > [RFC7517]. This same mechanism is used by [RFC8414]. Swap the mentions of RFC8414 and OpenID Connect: "As one example, Authorization Server Metadata [RFC8414] issuer values are .... The same mechanism is used by OpenID Connect [OpenID.Core]." > 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 would benefit from an explicit reference to Section 4.15 of RFC9700 https://datatracker.ietf.org/doc/html/rfc9700#section-4.15 which talks about the possibility of client_id vs user identifier confusion. Section 3.10: change "whitelist" to "allowlist". There is already a prior use of "allowlist" in the doc, so I assume this was unintentional. Also in section 3.10, mention that the AS should check what the hostname resolves to and avoid making a request if it resolves to a loopback or internal IP address. (e.g. someone uses the value "attacker.example.com/etc/passwd" as the jwks_uri, but adds a DNS entry for "attacker.example.com" to resolve to "127.0.0.1" or other internal IP address ranges. Section 3.11: "Sometimes, one kind of JWT can be confused for another." This is kind of vague and would benefit from more explicit examples. Thanks, Aaron On Fri, May 23, 2025 at 3:19 AM Yaron Sheffer <yaronf.i...@gmail.com> wrote: > > Hi everyone, > > > > RFC 8725 is the JWT Best Practices document that was published 5 years ago. > Since then, several new vulnerabilities and implementation issues were found, > and this is a “bis” document to inform the community of these issues and > recommend mitigations. > > > > This is a relatively small change to the existing BCP. We have (almost) > exhausted the issues we are aware of and we’re requesting adoption by the > working group. Once adopted, we believe we can quickly move to WGLC. > > > > Thanks, > > > > Yaron, Mike and Dick > > > > On 23/05/2025, 13:11, "internet-dra...@ietf.org" <internet-dra...@ietf.org> > wrote: > > A new version of Internet-Draft draft-sheffer-oauth-rfc8725bis-01.txt has been > > successfully submitted by Yaron Sheffer and posted to the > > IETF repository. > > > > Name: draft-sheffer-oauth-rfc8725bis > > Revision: 01 > > Title: JSON Web Token Best Current Practices > > Date: 2025-05-23 > > Group: Individual Submission > > Pages: 18 > > URL: > https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.txt > > Status: https://datatracker.ietf.org/doc/draft-sheffer-oauth-rfc8725bis/ > > HTML: > https://www.ietf.org/archive/id/draft-sheffer-oauth-rfc8725bis-01.html > > HTMLized: https://datatracker.ietf.org/doc/html/draft-sheffer-oauth-rfc8725bis > > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-sheffer-oauth-rfc8725bis-01 > > > > Abstract: > > > > 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. > > > > > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
