Skip to content

Combining IdToken and AccessToken Claims To Build Principal In Authorization Code Flow #53712

@amiru3f

Description

@amiru3f

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    api-suggestionEarly API idea and discussion, it is NOT ready for implementationarea-securityenhancementThis issue represents an ask for new feature or an enhancement to an existing one

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions