AWS OIDC authentication failure (Incorrect token audience) with two applications

[bagajjal]

Describe the bug

Please refer to https://github.com/aws/aws-sdk-net/issues/3071.

https://github.com/aws/aws-sdk-net/issues/3071#issuecomment-1802740896

https://github.com/aws/aws-sdk-net/issues/3071#issuecomment-1802850771

I apologize if this issue seems out of place here. If it is, please inform me of the appropriate GitHub repository to move this issue.

I'm currently working on implementing AWS OIDC authentication with Azure AD (AAD) as the OpenID provider. I have two applications (appId1, appId2). When using appId1 to authenticate with AAD, I obtain a token for appId2, meaning that the AAD access token has appId2 as its audience. Subsequently, I invoke AssumeRoleWithWebIdentityAsync() by providing the AAD access token. This configuration functions properly with AAD access token V1 but encounters issues with AAD access token V2 i.e., AWS OIDC authentication was successful using AAD access token V1 but not with AAD access token V2.

When utilizing AAD access token V2, if I employ appId2 for authentication with AAD and obtain a token for itself (where the AAD access token has appId2 as its audience) and present this token, the AWS OIDC authentication succeeds.

I have confirmed that my AWS account has the correct OIDC authentication configuration. Specifically, I have added appId2 to the OIDC clientID list, and appId2 has been granted assumeRole permissions to the AWS IAM role.

This seems to be a bug in the AWS OIDC authentication using AAD V2 access tokens using two AAD applications.

Please look into the attached document for more details, AWS_V2_accesstoken_error.docx

Expected Behavior

AWS OIDC authentication should succeed.

Current Behavior

AWS OIDC authentication fails with "Incorrect token audience" if we use AAD v2 access token with 2 applications.

Reproduction Steps

Create 2 applications in AAD, Azure AD. Using appId1 credentials authenticate with AD and request token for appId2. i.e., AAD will return AAD V2 access token with audience as appId2. Now call the AssumeRoleWithWebIdentityAsync() AWS OIDC authentication call fails with "Incorrect token audience".

Possible Solution

No response

Additional Information/Context

No response

AWS .NET SDK and/or Package version used

"AWSSDK.SecurityToken" Version="3.7.102.2"

Targeted .NET Platform

.NET 7

Operating System and version

windows 11

[ashishdhingra]

@bagajjal You mentioned This configuration functions properly with AAD access token V1 but encounters issues with AAD access token V2. I'm not particularly familiar with Azure AD. Could you please explain the differences you see w.r.t. format when using AAD token V1 vs V2?

[bagajjal]

@ashishdhingra , AAD access token v2 is introduced to support consumer accounts (user@hotmail.com). Looking at the AAD token presented to AWS, there is not much difference except that "idp" is populated in the AAD V1 access token but not in the AAD V2 access token.

Screenshot

Please look at the video recording using AAD access token v1 and access token v2. https://github.com/aws/aws-sdk-net/issues/3071#issuecomment-1802850771

[bagajjal]

@ashishdhingra , any update?

[Nikolajls]

@bagajjal did you ever get this to work with V2 JWT from Azure?

or anything from @ashishdhingra ?

I'm experincing quite the same where it seems impossible to configure OIDC provider for Azure Entra Id v2 JWT token always getting the audience error.

[Nikolajls]

@bagajjal and @ashishdhingra I'mgoing to post this here as it part of my issue and this likely is not anything related to the dotnet sdk.

When appA gets a entra v2 JWT for app B the token will have the following claims: azp - with a value of the party getting the token identity (APP A) aud - with a value of the audience APP B identity

However according to AWS oidc and role documentation:

• OIDC provider documentation

  If your IdP JWT token includes the azp claim, enter this value as the Audience value.

• Role condition documentation

  If no value is set for azp, the aud condition key maps to the aud claim.

the claim azp ( which is the value of the apiA) will override the value in the audience claim.

This results in the oidc provider having to contain a list for all app identities that are connected to APP-B for it work. Which does not seem feasible nor intentional that it overrides.

The role can modified to use the condition key oaud which directly reads the value from the aud claim (being appB in this case) However the oidc provider cannot be modified in any way for this behaviour.