-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
Is there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
Hey there,
Context
While using OpenIdConnectHandler
to leverage OIDC for handling authentication via external Identity Providers (like Duende, Google, Linkedin, AzureAD etc), after successful login and callback, the handler verifies the IdToken
and injects claims into the current request Principal
which means if the IDP puts claims into the IdToken
, the application can access it via request.Principal.Claims
Namely:
authenticationBuilder.AddOpenIdConnect(Schemes.AuthenticationSchemeInternal, "Sample", options =>
{
options.Authority = //sth
options.ClientId = //sth
options.ClientSecret = //sth
options.ResponseType = OpenIdConnectResponseType.Code;
options.GetClaimsFromUserInfoEndpoint = //Will explain this later
});
The OpenIdConnectHandler checks if the callback contains authorization code
which means the authentication was initiated in AuthorizationCode
flow, fetches the IdToken
and AccessToken
and then extracts the IdToken
claims. Then if GetClaimsFromUserInfoEndpoint
is enabled uses the AccessToken
to fetch the additional claims from the external IDP
Problem
IDPs like Duende
and AzureAD
do not put the claims inside the IdToken but AccessToken in case you use the authorization_code
flow. Unlike if you use implicit
, they put the claims into the IdToken
and the abovementioned works without any additional costs or issues.
So if you use authorization_code
, since the application does not read/care theAccessToken
, it needs another call to UserInfoEndpoint
to fetch the claims (Which might not be a good/performant case for all scenarios)
Describe the solution you'd like
My question/suggestion is why OpenIdConnectHandler
does not combine the claims from IdToken
and AccessToken
together to build the Principal
? Is this out of Standards/Protocols? Namely we can have a flag like options.AlsoCheckAccessTokenForClaims (default: false for avoiding breaking behaviours) so when you set the following flags it will get the claims from both and then no need to initiate another call to UserInfoEndpoint
:
options.GetClaimsFromUserInfoEndpoint = false;
options.ResponseType = OpenIdConnectResponseType.Code;
options.AlsoCheckAccessTokenForClaims = true;
Can you please help me to know if I'm thinking mistakenly against of the Protocol or Standards or any other downsides?
Additional context
No response