Strengthen JWT Security References in Client Authentication Section

[btiernay]

Strengthen JWT Security References in Client Authentication Section

Summary: Section 6.2 Client Authentication mentions private_key_jwt but could benefit from additional security guidance to help prevent cross-JWT confusion and weak algorithm usage.

Current Specification Language

From Section 6.2 Client Authentication:

For example, the client MAY include the following properties in its metadata document to establish a public key and advertise the private_key_jwt authentication method defined in [OpenID]:

{
  //...
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://client.example.com/jwks.json"
  //...
}

The section references OpenID Connect Core but doesn't include specific security guidance around JWT usage in the CIMD context (though Aaron mentioned having "a note in the draft about using this" that doesn't appear in the current published version).

Rationale

The current language could benefit from additional security guidance for authorization servers implementing CIMD. In real deployments, you often end up with multiple JWT types floating around - client authentication JWTs, access tokens, maybe attestation JWTs from draft-ietf-oauth-attestation-based-client-auth, and others. Without explicit typing and validation requirements, these JWTs might get confused or reused in the wrong context.

This builds on Aaron's feedback about referencing established mechanisms rather than defining new ones. RFC 7523 provides the JWT Profile for OAuth 2.0 Client Authentication foundation, and RFC 8725 contains helpful security guidance that could be referenced for production implementations.

Recommendation

Adding one paragraph to the end of Section 6.2 Client Authentication:

When using JWT-based client authentication methods such as private_key_jwt, authorization servers and clients MUST follow [RFC8725] (JSON Web Token Best Current Practices). In particular, client authentication JWTs MUST include an explicit typ header parameter (recommended value: oauth-client-auth+jwt) to prevent cross-JWT confusion attacks, and authorization servers MUST validate JWT types and implement algorithm allowlists.

And adding RFC8725 to normative references:

RFC8725:
  title: "JSON Web Token Best Current Practices"
  date: 2020-02
  target: https://www.rfc-editor.org/rfc/rfc8725.html

Related Work

• Complements Section 6.3 Changes in Client Keys which already covers key rotation scenarios, and proper JWT typing helps ensure security during key changes
• Builds on existing symmetric secret restrictions where the spec already prohibits client_secret_* methods in Section 4.1 Client Metadata and this extends that security thinking to JWT-based authentication
• Aligns with attestation work since the current draft already mentions draft-ietf-oauth-attestation-based-client-auth as a potential extension, and proper JWT typing becomes helpful when multiple authentication mechanisms are in play

Implementation Impact

This change would provide clearer security guidance for authorization server implementers without requiring protocol modifications. The requirements could be implemented as authorization server policy decisions and would complement the existing security considerations in Section 6.

[ThisIsMissEm]

This recommendation sounds good to me.