1

I have an implementation of identity server. One of the things I recently found out is that if I have a user claim (ex. picture) that is mapped to an API / API Scope (openid-api-scope), even if it is associated with an identity scope, the claim, is removed as an identity scope.

Why do you need the same user claim in both access token and userinfo endpoint?

As far as I know, access_token is for API / external system consumption while my end client will use the identity information from userinfo for client consumption. So to avoid getting a large identity token, It would be good to have the information available through the back channel call userinfo. I know the alternative is to set the AlwaysIncludeUserClaimsInIdToken to true.

Goal: Get the same user claim in access token and response from UserInfo endpoint without needing to AlwaysIncludeUserClaimsInIdToken = true

Example

please take note that picture here is just an example to illustrate the point and is not exactly the same user claim I intend to use this for.

Original Setup (default)

  • Identity Resource: openid
  • Identity Claim: picture
  • Client: AlwaysIncludeUserClaimsInIdToken: false

Client Scope: openid

Returns:

  • access token (with no picture claim)
  • id_token (no picture claim)
  • using access token against UserInfo : returns claims including picture)

Additional Setup

(assume that resource, scope and scope claim are associated)

  • API Resource : openid-api
  • API Scope : openid-api-scope
  • API Scope Claim : picture

Returns:

  • access token (with picture claim)
  • id_token (no picture claim)
  • using access token against UserInfo : does not return claims picture claim

Workaround

  • Client: AlwaysIncludeUserClaimsInIdToken: true

Returns:

  • access token (with picture claim)
  • id_token (with picture claim)
  • using access token against UserInfo : does not return claims picture claim
Community
  • 1
  • 1
MichaelChan
  • 1,808
  • 17
  • 34
  • The only app that needs the UserInfo is the client, responsible for the UI. There is no situation where a resource needs additional claims from the UserInfo endpoint. If information is needed for a request, then it's up to the client to add this information to the request, as part of the request. Please note that a JWT token is public readable. It contains information about the user that shouldn't be shared with all resources. –  Nov 26 '19 at 07:44
  • @RuardvanElburg like I said in my scenario, I do not intend the API to access the UserInfo, however, there are instances where a claim is relevant to the API and client, E.g. if I want to know if a user has permission to an API. The API would need the claim via access token and the client would need to know so they can decide, for example, to hide or show the link to access the access API. – MichaelChan Nov 26 '19 at 20:53
  • 1
    If a claim is relevant to the api, then you should add the claim type to the scope in order to get it into the access token, as explained [here](https://stackoverflow.com/questions/53976553/#54004765). But note, IdentityServer is for authenticating users and authorizing clients, PolicyServer is the recommendation for user authorization, as commented by one of the creators. From the article [Identity vs Permissions](https://leastprivilege.com/2016/12/16/identity-vs-permissions/#comment-131079). The article describes the problem and [PolicyServer](https://policyserver.io/) is the answer. –  Nov 26 '19 at 21:50
  • @RuardvanElburg thanks. It's kind of clear now. The best option (sans policy server) is to rely on a server-side backing API who can evaluate the user's access instead of relying on the client application to evaluate it. – MichaelChan Nov 26 '19 at 22:01

0 Answers0