Expected "profile" scope to return all user claims within tokens

[kansberry]

After stepping through code, I see two things. First, if an access token is requested the "AuthorizeResponseGenerator" passes "!request.AccessTokenRequested" to the "CreateIdentityTokenAsync" which indicates only standard claims should be returned. Second, in the "DefaultClaimsProvider" the "GetAccessTokenClaimsAsync" always only returns standard subject claims. Is this common practice? If so, are the applications that require additional claims expected to call the "UserInfo" endpoint? Seems to me it would be more efficient to simply pass claims to the secure resource that it needs rather than have it pull the claims on each request. At some point in the future will the "DefaultClaimsProvider" will be adjusted to take into account claims needed/required by the secured resource (i.e. with WIF, ADFS had a mechanism to say what claims it should pass in the token to be consumed by the secure resource)?

[brockallen]

Did you post this to the wrong repo?

[kansberry]

It is possible, I guess. I was using the Thinktecture AspNetIdentity example and found not all claims I added were being provided on the access token. I then realized in the "DefaultClaimsProvider" only provided "profile" claims within the OpenId token and even fewer on the access token. My question was whether this is common practice to only pass a small set of claims in the access token? I would think transforming the access token on each request would be "expensive" as compared to simply passing more claims within the access token. Additionally, I was asking if, like ADFS, there would eventually be a mechanism in Identity Server to define "new" claims and the claims to send within the access token for a particular client or relying party?

If this is not the correct place for me to be asking the question, I can close.

[brockallen]

It's a tradeoff and IdentityServer has flags so you can indicate how many claims go into each token. OIDC also defines the profile endpoint which is meant to be the API to access all the claims you've asked for. So in short, it's all very flexible and configurable for the tradeoffs you want to make.

And yes, there are extensibility points to define any claims you want to issue in either token or from the profile endpoint.