Version 5.x has been out of support since December 13, 2022, and this corresponding section of the documentation is no longer maintained. We strongly recommend upgrading to a supported version.


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

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

  • the identity of the client who is requesting the token
  • the identity of the user
  • what type of token is requested
  • the requested claim types according to the definition of the requested resources

You can use different strategies to determine which claims you want to emit based on that information

  • always emit certain claims (because they are an integral part of the user identity and needed in scenarios)
  • emit claims based on user or client identity
  • emit claims based on the requested resources

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);

        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

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.

Setting client claims dynamically

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.