Not getting user "email" as a claim (from jwt token) back from identity server

1
votes

I have a client on IdentityServer ,which allows openid,profile and email scopes :

  return new[] {
            new Client
            {
                ClientId = "TestWebApp",
                ClientSecrets = new [] { new Secret("TestSecret".Sha256()) },
                AllowedGrantTypes = GrantTypes.ResourceOwnerPasswordAndClientCredentials,
                AllowedScopes = new List<string>{ StandardScopes.OpenId, StandardScopes.Profile,StandardScopes.Email },
            }
        };

I have defined following Identity resources as well,

 public static IEnumerable<IdentityResource> IdentityResources()
    {
        return new IdentityResource[] {
                new IdentityResources.OpenId(),
                new IdentityResources.Profile(),
                new IdentityResources.Email()                
            };
    }

In-case the claim is missing , I am adding email to user claims explicitly while creation:

 await _userManager.AddClaimAsync(testUser, new Claim("email", user.Username));

Now from my login controller using ResourceOwnerPasswordAndClientCredentials I am sending authentication request : 

 var client = new OAuth2Client(new Uri("http://localhost:44322/connect/token"), "TestWebApp", "TestSecret");
 var requestResponse = client.RequestAccessTokenUserName(model.Email, model.Password, "openid profile email");

This works fine and I am getting the scopes back, but all of them are blank.

enter image description here

3
c#asp.net-coreasp.net-identityidentityserver4
You probably get access token, which gives you access to specified scopes. But to get email and other user info you should get id_token. - Slava Utesinov
Or you can call UserInfo endpoint providing this access token. - Slava Utesinov
@SlavaUtesinov, Do you have a example or a reference to an article? - Simsons
You are looking to use this docs.identityserver.io/en/latest/endpoints/userinfo.html - Vidmantas Blazevicius

3 Answers

6
votes

If you want to include the user claims in the Id token you can set AlwaysIncludeUserClaimsInIdToken to true on your client config.

  return new[] {
            new Client
            {
                ClientId = "TestWebApp",
                ClientSecrets = new [] { new Secret("TestSecret".Sha256()) },
                AllowedGrantTypes = GrantTypes.ResourceOwnerPasswordAndClientCredentials,
                AllowedScopes = new List<string>{ StandardScopes.OpenId, 
                    StandardScopes.Profile,StandardScopes.Email },
                AlwaysIncludeUserClaimsInIdToken = true
            }
        };
0
votes

You can include user claims in accesstoken when you specify those claims on Scopes. For instance for Swagger we needed to include the name claim if availible, below I dumped out the contents of what the ApiResource class should contain.

    {
    "ApiSecrets": [],
    "Scopes": [
        {
            "Name": "SwaggerApi",
            "DisplayName": "SwaggerApi",
            "Description": null,
            "Required": true,
            "Emphasize": false,
            "ShowInDiscoveryDocument": true,
            "UserClaims": ["name","email"]
        }
    ],
    "Enabled": true,
    "Name": "SwaggerApi",
    "DisplayName": "SwaggerApi",
    "Description": null,
    "UserClaims": ["name","email"]
}

Add this scope to the allowed scopes of your client registration.

Request an access token.

If the User has a name claim or email claim -> it should get added to the access token.

Result contents access token

  "idp": "oidc",
  "name": "MyUserName",
  "scope": [
    "openid",
    "profile",
    "SwaggerApi"
  ],
0
votes

When you use the resource owner password flow you’re requesting an access token, not an id token. Because of this, the claims associated with the scopes defined as identity resources are not passed in to your registered profile service implementation when the access token is created. If you really want to include the email in the access token then I’d advise you to make an api resource scope with “email” defined as a claim type.

That being said, if the email is being used for authentication purposes I’d suggest using another login flow that allows identity tokens if possible or using the user info endpoint.