OIDC, I cannot add extra claims from userinfo endpoint

[rcladmin]

In ASPNET Core 2.0, extra claims from the userinfo endpoint are not added to User.Claims in a MVC Client application. This worked in Core 1.1, what am I doing wrong? All I am getting is sid,sub,idp and email , all the other claims (including my custom claims) from the userinfo endpoint is missing. I checked the access_token int jwt.io and all the claims are there.

services.AddAuthentication(options =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
            })
            .AddCookie()
            .AddOpenIdConnect(o =>
            {
                o.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme; 
                o.RequireHttpsMetadata = false;
                o.Authority = "xxxxx";
                o.ClientId = "xxxx";
                o.ClientSecret = "xxxx";
                o.ResponseType = "code id_token";
                o.GetClaimsFromUserInfoEndpoint = true;
                o.SaveTokens = true;
                o.SecurityTokenValidator = new JwtSecurityTokenHandler
                {
                    InboundClaimTypeMap = new Dictionary<string, string>()
                };
                o.TokenValidationParameters.NameClaimType = "email";
            });

[Tratcher]

I wouldn't expect any differences. If you hook into Events.OnUserInformationReceived can you share the resulting json (see .User)?

Security/src/Microsoft.AspNetCore.Authentication.OpenIdConnect/Events/OpenIdConnectEvents.cs

Line 64 in 5abcfe7

public Func<UserInformationReceivedContext, Task> OnUserInformationReceived { get; set; } = context => Task.CompletedTask;

[rcladmin]

@Tratcher

The .User in Events.OnUserInformationReceived does show the additional claims as 'Children' tokens. However, these additional claims do not seem to be added to the Identity. I end up with only the claims from the original id_token and not the access_token.

I realised that if I use 'implicit' flow instead of 'hybrid' flow and delete the property o.ResponseType = "code id_token"; it works. I read this in a previous post and tried it. Any way, the code that works is shown below:

1. I used 'implicit' flow
2. I removed the Response.Type property from OpenIdConnectOptions

services.AddAuthentication(options =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
            })
            .AddCookie()
            .AddOpenIdConnect(o =>
            {
                o.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme; 
                o.RequireHttpsMetadata = false;
                o.Authority = "xxxxx";
                o.ClientId = "xxxx";
                o.ClientSecret = "xxxx";
                o.GetClaimsFromUserInfoEndpoint = true;
                o.SaveTokens = true;
                o.SecurityTokenValidator = new JwtSecurityTokenHandler
                {
                    InboundClaimTypeMap = new Dictionary<string, string>()
                };
                o.TokenValidationParameters.NameClaimType = "email";
            });

Is it that additional claims from the userinfo endpoint are not added for 'hybrid' flows? What do I need to do to get the 'hybrid' flow to work? It worked previously in ASP.NET Core 1.x.

[yosbeleg89]

I have exactly the same problem with the same configuration of @rcladmin. I resolved setting AlwaysIncludeUserClaimsInIdToken = true in the client configuration on the IdentityServer4 side, so it is not being obtained from the userinfo endpoint.

[rcladmin]

These are my findings so far:

1. 'Implicit' flow (response type : id_token) gets all the claims in the id_token (there is no access_token here, all the claims are in the id_token including extra and custom claims) and the claims are added to the identity. However, this flow does not cause a request to userinfo endpoint. Therefore, AlwaysIncludeUserClaimsInIdToken = true has no effect in the implicit flow. But this works, I am getting all my custom claims.

2. Hybrid flow (response type: code id_token) gets claims from id_token and adds it to identity. It causes a request from the userinfo endpoint and gets the extra claims in the access_token and puts it in the .User object as 'children' claims, but it does not add it to the Identity. Here you end up with none of your custom claims, just the intial claims in the original id_token.

So people using hybrid flow with custom claims or other additional claims not contained in the id_token but contained in the access_token may have problems.

Is it possible to debug the source code ? I would not mind to look at the following method in the source code to understand whats happening:

protected virtual async Task<HandleRequestResult> GetUserInformationAsync

Anyone who knows how I can go about debugging the OpenIdConnectHandler in some simple way, would be grateful for the assistance.

[Tratcher]

Ok, I know what's different here. See #1124 (comment). 2.0 no longer adds all possible information from the user-info endpoint, it was causing major cookie bloat leading to login issues. There is now a system called ClaimActions where you can select which elements you want to map from the user info doc to claims. See OpenIdConnectOptions.ClaimActions. Here are some examples:

Security/src/Microsoft.AspNetCore.Authentication.OpenIdConnect/OpenIdConnectOptions.cs

Lines 61 to 64 in 5abcfe7

	ClaimActions.DeleteClaim("ver");
	// http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
	ClaimActions.MapUniqueJsonKey("sub", "sub");

Security/samples/SocialSample/Startup.cs

Line 179 in 5abcfe7

o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email", ClaimValueTypes.Email);

[rcladmin]

@Tratcher

Hey, it works! Thanks for your help. For those having the same problem, this is my code.

1. Use 'hybrid' flow
2. Add the claims you want to include with o.ClaimActions.MapJsonKey

.AddOpenIdConnect(o =>
            {
                o.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                o.RequireHttpsMetadata = false;
                o.Authority = "xxxx";
                o.ClientId = "xxxx";
                o.ClientSecret = "xxxx";
                o.SaveTokens = true;
                o.SecurityTokenValidator = new JwtSecurityTokenHandler
                {
                    InboundClaimTypeMap = new Dictionary<string, string>()
                };
                o.TokenValidationParameters.NameClaimType = "email";
                o.ResponseType = OpenIdConnectResponseType.CodeIdToken;
                o.GetClaimsFromUserInfoEndpoint = true;
                o.ClaimActions.MapJsonKey("Contacts", "Contacts");
            });

[balkarov]

@Tratcher
Hi everyone!

I have the same issue but I try to include array (role claim).
So when I try to
ClaimActions.MapJsonKey("role", "role")
I get the Exception:

Cannot cast Newtonsoft.Json.Linq.JArray to Newtonsoft.Json.Linq.JToken

I tried to use MapCustomJson but I don't know how to return the array, threre is only string return type, not the List
ClaimActions.MapCustomJson("role", jObject => string.Join(',', ((JArray) jObject["role"]).ToObject<List<string>>()));

[Tratcher]

The existing extensions are for simple one-to-one json values to claims. In your case role is an array. Do you want that array stored as a single claim? If so you can just call ToString on it.

If you want multiple claims then you can create your own ClaimAction that does that.

Security/src/Microsoft.AspNetCore.Authentication.OAuth/Claims/ClaimAction.cs

Line 40 in 5abcfe7

public abstract void Run(JObject userData, ClaimsIdentity identity, string issuer);

[rcladmin]

@balkarov

Try:

1. o.ClaimActions.MapCustomJson("role", jobj => jobj["role"].ToString());
   This will return something like this example: "role" : ["Admin", "User", "Reader", "Contributor"]

2. Get an array of strings

o.ClaimActions.MapCustomJson("role", jobj =>
                {
                    IEnumerable<string> values = jobj["role"].Values<string>();
                    StringBuilder sb = new StringBuilder();
                    foreach (string val in values)
                    {
                        sb.Append(val + ",");
                    }
                    return sb.ToString().TrimEnd(',');
                });

This will return a string array like: "role" : "Admin,User,Reader"

You could always write more brief code to convert IEnumerable<string> to string[]

`

[yosbeleg89]

It worked for me too. Thanks @Tratcher

[balkarov]

@Tratcher thank you! It is work for me.
But why microsoft did not add "Role" claims by default in Asp Core ? I this "Role" is very popular claims.

public class JsonKeyArrayClaimAction: ClaimAction
{
    /// <summary>
    /// Creates a new JsonKeyArrayClaimAction.
    /// </summary>
    /// <param name="claimType">The value to use for Claim.Type when creating a Claim.</param>
    /// <param name="valueType">The value to use for Claim.ValueType when creating a Claim.</param>
    /// <param name="jsonKey">The top level key to look for in the json user data.</param>
    public JsonKeyArrayClaimAction(string claimType, string valueType, string jsonKey) : base(claimType, valueType)
    {
        JsonKey = jsonKey;
    }

    /// <summary>
    /// The top level key to look for in the json user data.
    /// </summary>
    public string JsonKey { get; }
    
    public override void Run(JObject userData, ClaimsIdentity identity, string issuer)
    {
        var values = userData?[JsonKey];
        if (!(values is JArray)) return;

        foreach (var value in values)
        {
            identity.AddClaim(new Claim(ClaimType, value.ToString(), ValueType, issuer));
        }
    }
}

And after

o.ClaimActions.Add(new JsonKeyArrayClaimAction("role", "role", "role"));

And after I can use User.IsInRole

[rcladmin]

@balkarov

I had the same question about Roles and Claims and this is what I found out:

1. Claims seems to be preferred for authorization than the traditional Membership/Roles we used in the past
2. Microsoft has provided a new table in Identity called RoleClaims as a 'fix' for traditional users of asp.net identity roles. Its mainly for backward compatibility.
3. Authorization Policy is based mainly on a User Claim and seemed to be the preferred method to protect controllers. You decorate your controller with [Authorize(Policy="ContactsRead')] instead of the traditional User.IsInRole. Although [Authorize(Roles="Admin")] is also supported, Policies are much more powerful and are even programmable.
4. As a example, you may have users in a 'Marketing' role, but some users can only read data, some can delete and some can add data. This cannot be accomplished by roles but can be accomplished by user claims. Each user in a role can also have different claims. And you use these claims for the security. Its a better system.
5. The concept of roles-based authorization is non-existent is modern identity systems (facebook, twitter, google, miscosoft, etc). Claim based authorization seems to be the 'defacto system'.

Microsoft supports role authentication if it is your preferred method:
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles

If you are interested claims and policies:
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims
https://stormpath.com/blog/tutorial-policy-based-authorization-asp-net-core