Retrieving the UserInfo should be optional

[jgrandja]

For OIDC authentication flow, fetching the UserInfo should be optional as we are able to leverage the id_token to complete the authentication.

We should provide a configuration to allow for enabling/disabling the fetching of the UserInfo for the OIDC authentication flow.

[kschulst]

Any progress on this?

We could revert to proceeding with user details from the id token...

[jgrandja]

@kschulst No progress on this as of yet. Working on other higher priority items.

The OAuth2AuthenticationToken.getPrincipal() will be an instance of DefaultOidcUser which contains both the IdToken and UserInfo. It's up to you which claims you want to access at this point as you have access to the ID Tokens claims and Standard Claims.

[kschulst]

Ah, thanks for the heads up. I'm doing a Proof of Concept of creating an AWS Cognito oauth client (which does not provide a /userinfo endpoint), and could probably easily get by with some local modifications then.

Let me know if it is interesting to contribute back an example of a Cognito integration ...

[vpavic]

My understanding of the OpenID Connect Core 1.0 spec is that the UserInfo Endpoint request is still required with Authorization Code Flow, at least when profile, email, address or phone scopes are requested.

From Section 5.4 of the spec:

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

So the OIDC compliant provider wouldn't include claims related to profile, email, address, and phone scopes in the ID Token when response_type value is code.

What are your thoughts on this @jgrandja @rwinch?

[jgrandja]

@kschulst I'm not familiar with AWS Cognito but if it implements OpenID Connect Core 1.0 then it will expose a UserInfo Endpoint.

However, if it does not implement OpenID Connect Core 1.0 and just implements standard OAuth 2.0 then it should still provide a non-standard API for obtaining information of the authenticated user.

Your AWS Cognito oauth client must be authorized by an authenticated user before it's receives an Access Token when using the Authorization Code Grant flow. After the oauth client receives the Access Token, it will then use it to initiate the request to the userinfo endpoint to obtain information for the authenticated user.

I would dig deeper into the AWS Cognito API's to see what endpoint they expose for obtaining information for the authenticated user.

[jgrandja]

@vpavic Yes that is correct, when response_type=code (authorization code grant) then the claims linked to the scopes profile, email, address, phone will not be returned in the ID Token. The only claims returned in the ID Token will be the standard ones.

However, we still can achieve authentication for OIDC authorization code grant flow because the ID Token contains the iss and sub claim which uniquely identifies a user for a specific provider. Hence the call to /userinfo in this case can be optional. Make sense?

[vpavic]

Hey @jgrandja - yes, it makes sense. My comment was probably more suited for #4312 but since that one was closed I decided to comment here as the two are related.

I should have added that I do agree that call to UserInfo endpoint should not be mandatory. However, the moment that change is made the question of what should be the default behavior pops up.

As a user, if I issue an authorization request (or better said authentication request considering the OIDC context) with additional OIDC scopes (profile, email, address or phone) I'd expect the framework to populate the Authentication with claims obtained from UserInfo endpoint. Similarly, if the request doesn't specify additional OIDC scopes it makes sense to skip the UserInfo call. That suggests that the default should perhaps be automatic depending on the context (i.e. scopes) of current auth request.

That sort of implies 3 values for configuring UserInfo call behavior - auto (dependent on auth request), enabled (i.e. always on) and disabled (i.e. always off) with auto being default. What do you think?

[jgrandja]

@vpavic Yeah #4312 was logged a while back and back then I wasn't familiar with the spec as much so wasn't sure of the difference between IdToken and UserInfo.

Excellent point as far as the 3 configuration values: auto, enabled, disabled. The auto value makes total sense if the user has configured at least one of these scope values for the client: profile, email, address, phone given that none of the claims linked to these scopes are returned in the IdToken during the authorization code flow so we need to account for this case.

Thanks for noting this here. I will consider this when I get to this issue.

[jgrandja]

@vpavic I finally got around to this issue. I was able to derive the logic without having to require a configuration setting. See this