Relax quarkus-oidc requirement that UserInfo endpoint must be available for OAuth2 login to succeed #52651
Description
Description
Right now, when it is a pure OAuth2 provider such as GitHub, Spotify, etc, that do not issue an ID token but only an access token, but have no token introspection or jwks endpoints, Quarkus OIDC insists that a provider specific UserInfo endpoint must be available.
This is done for 2 reasons:
- To give the application an option to access the user related info that would typically be available in ID token
- Have a mechanism to verify the access token indirectly since in order to access the provider specific UserInfo endpoint, the access token must be supplied and therefore verified at the provider side
However some providers may not even have a provider specific UserInfo endpoint in their API or make it rather difficult to access it (ex, Atlassian).
Sometimes the applications don't even need to have a user info of any kind but just login using the authorization code flow and use the access token to access some API like JIRA API in case of Atlassian.
It also makes it awkward to handle dynamic cases such as those supported by the MCP authorization, for example, when importing Github MCP servers where all that is needed for an MCP host is to get the access token, no extra UserInfo requests are required.
From the security point of view when logging in to such OAuth2 providers, what is important is that the authorization code flow has succeeded and Quarkus OIDC has a session represented by an internal ID token.
If the code will inject @UserInfo - Quarkus OIDC will enforce it - but if all the application cares about is having an @Authenticated access - we should make it easy without forcing users to have UserInfo fetched.
Implementation ideas
If a user has configured quarkus.oidc.authentication.id-token-required=false and explicitly informed Quarkus OIDC that quarkus.oidc.authentication.user-info-required=false then Quarkus OIDC must not enforce the user info acquisition