Potential Attack Vector

[AxelNennker]

Problem Description

The CAMARA Security Interoperability Profile currently requires that the aud (audience) claim in JWT assertions should be set to the URL of the endpoint to which the request is sent. This requirement creates a security vulnerability known as "Audience Injection Attack" that has been identified by University of Stuttgart researchers and is being addressed by the IETF in draft-ietf-oauth-rfc7523bis-04.

This attack vector is then a problem IF metadata is retrieved. Hardcoded aud-values should be secure.

Affected Sections

1. Signed Authentication Requests (OIDC Authorization Code Flow)

   • Current text: "It is RECOMMENDED that the value of the aud field of the signed authentication request is the URL of the Authorization Endpoint."

2. Client-Initiated Backchannel Authentication Flow

   • Current text: "It is RECOMMENDED that the value of the aud field of the signed authentication request is the URL of the Backchannel Authentication Endpoint."

3. JWT Bearer Flow

   • Current text: "The mandatory aud claim MUST be the URL of the endpoint this token request is sent to."

4. Client Authentication

   • Current text: "This document RECOMMENDS that the aud (audience) claim in the client assertion SHOULD be the full URL of the specific endpoint at the Authorization Server to which the client is sending the request."

The Vulnerability

The attack works as follows:

1. Attacker's Authorization Server (evil-as.example.com) publishes metadata claiming its token endpoint is at a different URL (e.g., https://honest-as.example.com/token)
2. API Consumer creates a JWT with aud: https://honest-as.example.com/token (following current CAMARA guidance)
3. Attacker captures this JWT and replays it at the honest authorization server
4. Honest Authorization Server accepts the JWT because the audience matches its token endpoint URL

This attack is possible because:

• Discovery metadata (RFC 8414) is typically served over TLS but only "issuer" is validated
• A malicious authorization server can lie about its token_endpoint in its metadata
• If the audience is the token endpoint URL, JWTs intended for one AS can be replayed at another AS that happens to have the same endpoint URL

The Solution (per draft-ietf-oauth-rfc7523bis-04)

The IETF working group has determined that the aud claim MUST be the issuer identifier of the authorization server (not the token endpoint URL) for client authentication JWTs.

This prevents the attack because:

1. Clients MUST validate that the issuer field in metadata matches the URL from which the metadata was retrieved (RFC 8414 Section 3.3 requirement)
2. Each authorization server only accepts JWTs with aud set to its own issuer identifier
3. A JWT created for evil-as.example.com cannot be replayed at honest-as.example.com

The defense relies on proper client validation: if metadata is fetched from https://evil-as.example.com/.well-known/oauth-authorization-server, the issuer field MUST be https://evil-as.example.com or the metadata MUST be rejected.

Proposed Changes

1. Update "Signed Authentication Requests" Section

Current:

It is RECOMMENDED that the value of the `aud` field of the signed authentication request is the URL of the Authorization Endpoint.
The authorization server MAY accept different values of the `aud` field e.g. the `issuer` field of its OpenID Provider Metadata.

Proposed:

The value of the `aud` field of the signed authentication request MUST be the `issuer` identifier of the authorization server as defined in RFC 8414.

2. Update "CIBA Authentication Request" Section

Current:

It is RECOMMENDED that the value of the `aud` field of the signed authentication request is the URL of the Backchannel Authentication Endpoint.
The authorization server MAY accept different values of the `aud` field e.g. the `issuer` field of its OpenID Provider Metadata.

Proposed:

The value of the `aud` field of the signed authentication request MUST be the `issuer` identifier of the authorization server as defined in RFC 8414.

3. Update "JWT Bearer Flow" Section

Current:

- The mandatory `aud` claim MUST be the URL of the endpoint this token request is sent to.

Proposed:

- The mandatory `aud` claim MUST be the `issuer` identifier of the authorization server as defined in RFC 8414.

4. Update "Client Authentication" Section

Current:

This document RECOMMENDS that the `aud` (audience) claim in the client assertion SHOULD be the full URL of the specific endpoint at the Authorization Server to which the client is sending the request.

Proposed:

The `aud` (audience) claim in the client assertion MUST be the `issuer` identifier of the authorization server as defined in RFC 8414. The authorization server MUST reject any client authentication JWT that does not contain its own issuer identifier as the sole audience value.

Client authentication JWTs SHOULD be explicitly typed by using the `typ` header parameter value `client-authentication+jwt` as defined in draft-ietf-oauth-rfc7523bis.

5. Add Security Considerations

Add a new subsection under the relevant sections:

#### Audience Validation

API Consumers MUST validate that the `issuer` value in the authorization server metadata exactly matches the issuer identifier used to construct the metadata URL, as required by RFC 8414 Section 3.3. If these values do not match, the metadata MUST be rejected to prevent audience injection attacks.

Authorization servers MUST reject JWT assertions (for both client authentication and JWT bearer grants) if the `aud` claim does not exactly match the authorization server's own issuer identifier.

References

• [draft-ietf-oauth-rfc7523bis-04 - Updates to OAuth 2.0 JWT Client Authentication](https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/)
• [RFC 8414 - OAuth 2.0 Authorization Server Metadata, Section 3.3](https://www.rfc-editor.org/rfc/rfc8414.html#section-3.3)
• [OIDF Responsible Disclosure on private_key_jwt Vulnerability](https://openid.net/2025/01/24/oidf-responsible-disclosure-notice-on-security-vulnerability-for-private_key_jwt/)
• [Audience Injection Attacks Research Paper](https://eprint.iacr.org/2025/629)

Priority

This is a security vulnerability that should be addressed in the next release of the CAMARA Security Interoperability Profile.

[jpengar]

Thanks @AxelNennker. I think the following diagram illustrates the reported vulnerability for easier understanding:

One thing we would need to address is that the suggested change to the ICM profile is not backward compatible. As has been mentioned before, CAMARA has not yet defined how to handle changes to ICM definitions and guidelines that are not backwards compatible.

@camaraproject/release-management_codeowners This is something that we may need to address in camaraproject/ReleaseManagement#351

It would be necessary to establish timeframes for supporting each ICM release and for upgrading to a new ICM version after its release. For example, the fact that the current versions of ICM aren't stable could mitigate the impact. However, if we transition to a stable version, the situation changes.

Then, for instance, we would need to clarify whether exceptions can be applied to these rules for addressing security vulnerabilities ASAP. This could be the case with this issue.

[jpengar]

After analyzing the paper “Audience Injection Attacks: A New Class of Attacks on Web-Based Authorization and Authentication Standards” and reviewing the current CAMARA Security Interoperability guidelines, from Telefónica point of view, we believe that the practical risk of this vulnerability affecting CAMARA deployments may not be that high.

Our analysis covers the following key points:

• CAMARA has a restricted ecosystem and onboarding process: The "Audience Injection" attack requires the victim (Client) to initiate an authentication process against an Attacker-controlled Authorization Server (AS). In the CAMARA ecosystem, there is no Dynamic Client Registration for example. Every Operator/API Provider undergoes a rigorous onboarding and vetting process. An attacker would find it extremely difficult to masquerade as a legitimate Operator within the trust chain (Aggregators/Telco Finder) to trick a client into using a malicious AS.

• Destination-Based Audience Mitigation: The paper suggests restricting the audience value to the specific endpoint URL being called as an effective mitigation. This option is described in Section 5 of the paper, along with using the Auth Server issuer as the audience. CAMARA already implements this recommendation:

  "This document RECOMMENDS that the aud (audience) claim in the client assertion SHOULD be the full URL of the specific endpoint at the Authorization Server to which the client is sending the request." Using the full endpoint URL (including the host and path) as the audience claim means that an assertion sent to an attacker's introspection, CIBA, or other endpoint mentioned in the paper would be cryptographically bound to that specific URL. Consequently, the assertion could not be replayed at a legitimate operator’s token endpoint.

  Also, note that this recommendation to use the destination endpoint as the audience was defined in CAMARA to prevent cross-protocol attacks. This recommendation avoids using assertions for purposes other than those for which they are intended. Draft-ietf-oauth-rfc7523bis-05 recommends using the "typ" field to specify the assertion type (e.g., "client-authentication+jwt") to mitigate this issue.

• Signed Request Protections: For signed authentication requests, the CAMARA profile recommends excluding the sub field to prevent these objects from being misused for client authentication. This provides an additional layer of defense-in-depth against assertion reuse.

In conclusion, we recommend that the WG evaluate whether there is an immediate critical risk that warrants breaking backward compatibility, such as mandating the use of AS as the issuer and audience, which would impact existing integrations. While we agree that aligning with upcoming industry standards is beneficial, we recommend reinforcing the requirement that clients derive the AUD value from the actual destination URL of the request. In the medium to long term, the WG should consider transitioning to using the iss (Issuer Identifier) as the unique audience value, as proposed in draft-ietf-oauth-rfc7523bis, if necessary. Also, the WG may decide to wait for the draft to become an RFC.

In any case, we believe that we still need to discuss and agree on how to handle ICM releases and breaking changes with Release Management WG, as mentioned in the above comment.

[jpengar]

For the record, as discussed yesterday during the ICM call (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/521437188/2026-01-28+ICM+Minutes), the working group (WG) agreed that the current ICM recommendations are likely sufficient.

• The WG will consider adding an editorial clarification stating that the vulnerability does not affect CAMARA’s approach.
• There will be no immediate changes to the ICM document, but there is potential for an editorial update during the finalization phase of the meta-release.

CC @AxelNennker

[jpengar]

@AxelNennker Do you have an update on the IETF's discussion about this attack vector? Are you planning to include the editorial clarification stating that the vulnerability does not affect CAMARA's approach? This would be required before the public release of Spring26.

[mhfoo]

@jpengar @AxelNennker

The following is my view and proposal:

"aud" (Audience) Claim

In the general case, the "aud" value is an array of case-sensitive strings, each containing a StringOrURI value.

Since the JWT Specification allows an array, we can propose to include both a) the issuer identifier of the authorization server as defined in RFC 8414, and b) the URL of the intended endpoint. The authorization server must ensure both the intended endpoint and its issuer identifier are present and valid; else reject the JWT.
This applies to all 4 scenarios:

1. Signed Authentication Requests,
2. CIBA Authentication Request,
3. JWT Bearer Flow and
4. Client Authentication.

Using the following example OpenID Provider Configuration Response

{
   "issuer": "https://server.example.com",
   "authorization_endpoint": "https://server.example.com/connect/authorize",
   "token_endpoint": "https://server.example.com/connect/token",
   "backchannel_authentication_endpoint": "https://server.example.com/connect/bc-authorize",
...
}

Example JWT aud for CIBA Authentication Request:

"aud": [
    "https://server.example.com",
    "https://server.example.com/connect/bc-authorize"
  ],
...

Please let me know what do you think and your comments.

[jpengar]

@mhfoo During the most recent ICM call (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/595132423/2026-02-25+ICM+Minutes), the group reaffirmed the previous conclusion that the audience-injection vulnerability would not affect CAMARA's approach, and that the current ICM recommendations are likely sufficient.

For the Spring26 meta-release, The WG is going to add an editorial clarification to the ICM profile stating that CAMARA is not vulnerable. This is being discussed in #348.

This issue will remain open while IETF work continues. Once the IETF and the OpenID Foundation have updated their RFCs and specifications, ICM will revisit this issue.

CC @AxelNennker