Implicit client authentication in JWT bearer flow

[sfnuser]

Problem description
The JWT Bearer flow treats the JWT authorization grant assertion as implicit client authentication, based on successful signature validation using the public key associated with the iss claim (client_id).

Traditionally, Authorization Server (AS) implementations follow a token endpoint processing model in which:

• the client is treated as a confidential client, and
• explicit client authentication (e.g. private_key_jwt, mTLS, or client_secret) is performed prior to grant evaluation

It is currently unclear:

• whether there are known AS implementations that support this JWT Bearer flow — where the authorization grant assertion itself serves as client authentication — without requiring customization or non-standard extensions. In practice, the token endpoint is shared across multiple grant types (e.g. authorization_code, jwt-bearer, client_credentials, CIBA), and AS implementations typically apply authentication, policy, audit, and logging uniformly at the token endpoint level. It is therefore unclear how processing the grant prior to client authentication only for the jwt-bearer grant is expected to be implemented.
• how such implementations handle token endpoint processing for unauthenticated or malicious requests;
• and how error handling is achieved consistently in this model. For e.g, when an iss corresponds to a valid but incorrectly configured client_id, it is unclear whether the appropriate error should be invalid_client or invalid_grant, and whether this behavior is intentional or implementation-dependent.

This lack of clarity may lead to inconsistent implementations & interoperability issues

Expected action
Provide additional clarification or guidance in the documentation to address the practical implementation aspects of the JWT Bearer flow, including:

• Document known or recommended implementation patterns for Authorization Servers, including whether explicit client authentication in addition to the JWT Bearer grant is acceptable, optional, or discouraged in CAMARA-compliant deployments, with the goal of supporting interoperability across common AS products.
• May have to acknowledge that JWT Bearer flows require the AS to process untrusted input at the token endpoint. Should we provide some recommendations (e.g. rate limiting, request size limits, algorithm restrictions, early rejection rules) to mitigate denial-of-service or resource exhaustion risks?
• Clarify expected error semantics (invalid_client vs invalid_grant) when failures occur during JWT Bearer token request processing, particularly when failures occur before or during grant validation.

[AxelNennker]

JWT Bearer Flow is not a CAMARA invention but a profile of Using JWTs as Authorization Grants and of Using Assertions as Authorization Grants

In Keycloak this is a preview feature: https://www.keycloak.org/securing-apps/jwt-authorization-grant
In Connect2id this documented here: https://connect2id.com/products/server/docs/guides/oauth-jwt-grant-for-backend-services

Regarding @sfnuser 's question, are details missing in rfc7523 and rfc7521 that need to be profiled in CAMARA?
Are e.g. the above two implementations different in an important way?

[sfnuser]

@AxelNennker - Thank you for the vendor links. Connect2id explicitly states: This grant also has the feature that the JWT can be used to also authenticate the client, so there is no need for client to authenticate explicitly. - which aligns perfectly with CAMARA's profile requirements.

Yes, the implementations differ:

• Keycloak enables the JWT Authorization Grant primarily for confidential clients only, requiring explicit client authentication before evaluating the grant assertion.
• While customization via SPI is possible in Keycloak, this is not the default/standard behavior.
• In contrast, Connect2id supports implicit client authentication via the JWT assertion itself (with iss matching client_id and signature validation).
• Many vendors (e.g., Okta, ORY Hydra, Ping Identity) show examples or configurations that include explicit client_id or separate client authentication.

CAMARA explicitly describes client authentication as implicit in the JWT Bearer Flow: the token request JWT assertion is signed by the API Consumer, and the assertion is interpreted as Client Authentication. While RFC 7523 leaves client authentication optional and open to interpretation, this vendor variance underscores the need for clearer CAMARA guidance.

This is precisely why I requested clarifications/discussions on the following topics and some of these aspects can be profiled in CAMARA:

• Document known or recommended implementation patterns for Authorization Servers, including whether explicit client authentication (in addition to the implicit JWT Bearer grant) is acceptable, optional, or discouraged in CAMARA-compliant deployments - to better support interoperability across common AS products like Keycloak, Connect2id, etc.
• Because of implicit client authentication, we may have to acknowledge that JWT Bearer flows require the AS to process untrusted input at the external facing token endpoint (parsing, decoding, client_id extraction, pubkey lookup, signature verification). Should we provide recommendations (e.g., rate limiting, request size limits, algorithm restrictions like disallowing 'none', early rejection rules) to mitigate denial-of-service or resource exhaustion risks?
• Clarify expected error semantics (invalid_client vs invalid_grant) during JWT Bearer token request processing, especially for failures before/during grant validation. For e.g., Connect2id may return invalid_grant even for client_id issues or signature failures due to its implicit auth model. Consistent error handling would improve interoperability.

Looking forward to your thoughts