The userinfo endpoint is not designed for APIs
A common (but incorrect) practice I often see people doing is using the OIDC userinfo endpoint from APIs. It seems like a natural thing to want to do — you have an access token in your API and it contains identity scopes. This means the access token can be used at the userinfo endpoint to access the identity data for those scopes (like profile, email, phone, etc.). The problem is that the userinfo endpoint is designed for the client, not the API (after all, userinfo is defined in the OIDC spec, not the OAuth2 spec).
Another way to think of the problem is that the API has no control over the scopes that access token has been granted. The client controls those scopes. This means your API is taking a dependency on the identity information the client is configured to obtain from the token server, and this is quite brittle. If the client ever changes what identity scopes they request, your API is affected.
A better approach is to configure your API to request the claims that it needs for the user. That’s why there’s a UserClaims property on the ApiResource (and Scope) configuration object model(s) in IdentityServer. These configured user claims will be delivered to the API in the access token itself (or from introspection if using reference tokens). This allows your API to be explicit about what it needs about the user, regardless of the client’s configuration.
brockallen 
Brock, this is such an interesting topic. Depending on who you talk to, you get a different answer. Auth0 loves to pass JWT’s. Other OAuth guru’s insist passing the access token to the API is fine–even positing that’s what access tokens were made for. You’re solution–to configure your API to request the claims that it needs for the user–sounds ideal. But how does this translate into a standard OpenID Connect flow?
I don’t follow. In IdentityServer we have config to model APIs, and as part of that config we allow an API to express what identity data it needs for a user. In a sense, it’s unrelated to OIDC.
Oh ok. Thanks for the reply.
What about the case number of claims would make token so large? I was thinking (perhaps wrongly?) that token has minimum set of claims to allow user in, then on the backend I can get rest of claims using UserInfo endpoint. Is this a valid use case?
Use introspection if that’s the situation.
Also, userinfo is for minimizing the id token size, not the access token.
@brockallen: that clarifies, many thanks:)