ClaimsPrincipal on ASP.NET Core v8.0.100-rc.2.23502.2 Doesn't Contain All Claims From The OpenIdConnect Token

[smjxpro]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

I have an existing Blazor project which was in .NET 8 RC1. After upgrading to .NET 8 RC2, authentication and authorization using OIDC (Keycloak) isn't working as expected.

For example, on my IClaimsTransformation implementation I could access the realm_access property like this: var realmAccessValue = principal.FindFirst("realm_access")?.Value;

Also, the exp, email_verified except for a few is missing on the ClaimsPrincipal object.

Expected Behavior

The ClaimsPrincipal object should contain all the token claims.

Steps To Reproduce

1. Create a new Blazor Web App project without interactivity
2. Add Microsoft.AspNetCore.Authentication.OpenIdConnect 8.0.0-rc.2.23480.2
3. Configure to use Keycloak or any other OIDC provider
4. Create and register an IClaimsTransformation implementation and register it in DI
5. On the TransformAsync method try to access some values which is on the token (jwt.io). For example for Keycloak: var realmAccessValue = principal.FindFirst("realm_access")?.Value;
6. The value is null

Exceptions (if any)

No response

.NET Version

8.0.100-rc.2.23502.2

Anything else?

No response

[mschaefer-gresham]

I have a similar issue. The 'email' claim is not present when attempting to do a claims transformation after upgrading to 8.0.0-rc.2. In my case, I'm reading the access token sent in the header.

var email = principal.Claims.FirstOrDefault(c => c.Type == "email")?.Value;

I fixed this issue by downgrading Microsoft.AspNetCore.Authentication.JwtBearer from 8.0.0-rc.2.23480.2 to 7.0.13.

[miaooss]

I was able to make it work by reverting on Microsoft.AspNetCore.Authentication.JwtBearer 8.0.0-rc.1.23421.29

But the rc2 8.0.0-rc.2.23480.2 has an issue with the token and now the Release version 8.0.0 since to have the issue as well.

[mschaefer-gresham]

@Tratcher are there plans to address this issue soon?

[miaooss]

We found the Issue was on our TokenService

We use the identity server and for some reason, our jwt token had an array for the iat property

IDX11020: The JSON value of type: 'StartArray', could not be converted to 'JsonTokenType.Number'. Reading: 'System.IdentityModel.Tokens.Jwt.JwtPayload.iat', Position: '246', CurrentDepth: '1', BytesConsumed: '247'.

It might be a different issue, But for my part, we fix it on our TokenService

It's related to my previous comment

[josephdecock]

@miaooss, if necessary, you can also open an IdentityServer issue.

[mschaefer-gresham]

@Tratcher any movement on this issue?

[CPlusPlus17]

I can confirm that we see the same problem with keycloak, revert to 7.x and it works again.

[mschaefer-gresham]

Are there any plans to address this soon?

[oluatte]

Also facing this problem. Any alternatives or plans to fix?

PS. Happy new year, all!

[mschaefer-gresham]

I can confirm this is still an issue in SDK 8.0.101.

[mschaefer-gresham]

Because we can't upgrade to 8.0.101 we are now vulnerable to this risk: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/security/advisories/GHSA-8g9c-28fc-mcx2

Why is this issue still not being looked at?

[oluatte]

I was able to get the claims i needed (e.g. exp) thanks to this helpful post.

// keep these claims from the id token when creating the claims identity options.ClaimActions.Remove("iat"); options.ClaimActions.Remove("exp");

There are default claim actions to remove some of the more estoric claims. You can choose to remove the claim actions to allow those claims to be mapped.

[mschaefer-gresham]

Opened new issue 53842.

[mkArtakMSFT]

@jennyf19 it looks like there was a breaking change in the IdentityModel update we took for 8.0-rc2. Should this have been documented as a breaking change too in 8.0 or was it not intentional and you can revert that behavior on your end (in IdentityModel)? It's surprising that the fix from 2017 (from blog post mentioned earlier) worked.

[mkArtakMSFT]

To people who still experience problems here, please try the following:

OpenIdConnectOptions.ClaimActions.Clear();

[mschaefer-gresham]

@mkArtakMSFT so this should be called in AddOpenIdConnect()?

 .AddOpenIdConnect(options =>
        {
            options.Scope.Clear();
            ...

If so, I can confirm this does not solve the issue.

In my case, I am using AddOpenIdConnect in my api gateway, whereas I experience this claims issue in my downstream api that I am passing the jwt to. In my api app I am also calling:

 JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

[mschaefer-gresham]

@mkArtakMSFT the email address claim is there, but the type is no longer "email". Now it's "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress".

[mschaefer-gresham]

If I instead use the type above, then I can get things working:

var email = principal.Claims.FirstOrDefault(c => c.Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress")?.Value;

But what happened to the claim of type "email"?

[mschaefer-gresham]

I ended up solving my issue with the email claim by using ClaimTypes.Email.

var email = principal.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value;

[dotnet-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.