IdentityServer emits claims about users and clients into tokens. You are in full control of which claims you want to emit, in which situations you want to emit those claims, and where to retrieve those claims from.
User claims can be put in both identity and access tokens. The central extensibility point to implement for emitting claims is called the profile service.
Whenever IdentityServer creates tokens for a user, it invokes the registered profile service with a context that presents detailed information about the current token request, including
You can use different strategies to determine which claims you want to emit based on that information
Generally speaking, we recommend using the resource definitions to associate user claims with resources. In that case your profile service receives an aggregated list of requested claim types based on the requested resources. The implementation is then as simple as returning the corresponding claim values back to the runtime.
Here’s a sample implementation of a profile service:
public class SampleProfileService : IProfileService
{
// this method adds claims that should go into the token to context.IssuedClaims
public virtual Task GetProfileDataAsync(ProfileDataRequestContext context)
{
var requestedClaimTypes = context.RequestedClaimTypes;
var user = context.Subject;
// your implementation to retrieve the requested information
var claims = GetRequestedClaims(user, requestedClaimsTypes);
context.IssuedClaims.AddRange(claims);
return Task.CompletedTask;
}
// this method allows to check if the user is still "enabled" per token request
public virtual Task IsActiveAsync(IsActiveContext context)
{
context.IsActive = true;
return Task.CompletedTask;
}
}
The Subject property on the ProfileDataRequestContext contains the principal that was issued during user sign-in. Typically, the profile service will source some claims from the Subject and others from databases or other data sources.
The profile service also gets called for requests to the userinfo endpoint. In that case, the Subject property will not contain the principal issued during user sign-in, since userinfo calls don’t happen as part of a session. Instead, the Subject property will contain a claims principal populated with the claims in the access token used to authorize the userinfo call. You can check the caller of the profile service by querying the Caller property on the context.
Client claims are typically statically defined claims that get emitted into access tokens. The following shows an example of a client that is associated with a certain customer in your system:
var client = new Client
{
ClientId = "client",
// rest omitted
Claims =
{
new ClientClaim("customer_id", "123")
}
};
All client claims will be by default prefixed with client to avoid accidental collision with user claims, e.g. the above claim would show up as client_customer_id in access tokens. You can change (or remove) that prefix by setting the ClientClaimsPrefix on the client definition.
By default, client claims are only sent in the client credentials flow. If you want to enable them for other flows, you need to set the AlwaysSendClientClaims property on the client definition.
If you want to set client claims dynamically, you could either do that at client load time (via a client store implementation), or using a custom token request validator.