Getting all the claims from a WebApi for a user in Identity Server 4

Question

I've gone through the examples of Ids4 specifically the client-webapi scenario.

https://github.com/IdentityServer/IdentityServer4/tree/master/samples/Clients

The example mostly illustrate how the client gets the access token, sends the acess token to the WebAPI and the WebAPI doing a check based on policy like scope or claim.

My scenario has the following constraints.

• The access token contains minimal information. Meaning I don't put all of the information which are mostly sensitive in it.
• The WebAPI requires those claims for the policy (not just scope) because the claim will be specific to a user, not the client application.

Example

options.AddPolicy("User", policy =>
{
    policy.RequireClaim("ProfileAccess","user:read");
});
options.AddPolicy("Admin", policy =>
{
    policy.RequireClaim("ProfileAccess", "user:read", "user:write");
});

In an MVC client, OpenId Connect configuration has an option GetClaimsFromUserInfoEndpoint which calls the UserInfo endpoint using the token and turns those claims into claims for the principal. Is there something similar for WebAPI or do I have to implement it myself? I don't want to include too much information in the access token either.

Answer 1

The simplest ways is to include the needed claim in access token when Identity Server issues access token . So that API will get the claims after validating the token and you can create policy requirement to check the claim . You can define the API resources to include the user claim . See defining API resources :

http://docs.identityserver.io/en/latest/reference/api_resource.html#refapiresource

You can find there's a UserClaims property on the ApiResource (and Scope) to add list of associated user claim types that should be included in the access token.

GetClaimsFromUserInfoEndpoint is not designed for APIs , see this article for more details .

If you don't want to inlcude the claim in tokens , you can use delegation fow to acquire new access token to get the user's information .

Answer 2

It looks, what you need is a kind of Extension grant , namely delegation .

You want to give your API more access, than your client has, but you can't use just ClientCredentials flow or grant as it doesn't carry user information. That's exactly the case where delegation could help: you bring your API a token with the sub (userId) claim only, and API requests a totally new token, providing it's own credentials together with the original token.

Answering the original question: despite of it's technically possible to use the original token, coming to the API with a request from the client, it does not improve the security: if your Client is JS-app and it keeps the original token in Session or Local storage in browser, everyone can get that token and call UserInfo endpoint from curl or postman .