My Current Setup is:
I have an Identity server built using Duenede.IdentityServer package running at port 7025.
I have a WebApi which is Dotnet 6 based and below is its OIDC configuration.
AddOpenIdConnect("oidc", o => { JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); o.SaveTokens = true; o.GetClaimsFromUserInfoEndpoint = true; o.RequireHttpsMetadata = false; o.ResponseType = "code"; o.Authority = "https://localhost:7025/"; o.ClientId = "some clientid"; o.ClientSecret = "some secret"; o.Scope.Clear(); o.Scope.Add("openid"); o.Scope.Add("profile"); o.Scope.Add("dotnetapi"); o.NonceCookie.SameSite = SameSiteMode.Unspecified; o.CorrelationCookie.SameSite = SameSiteMode.Unspecified; o.ClaimActions.MapUniqueJsonKey("role", "role"); o.ClaimActions.MapUniqueJsonKey("email", "email"); });
Now when web api request the token from the identityserver (OIDC is the challenge scheme and i have a cookie scheme set as default authentication scheme) it gets both id_token and access_token(verified using await HttpContext.GetTokenAsync("access_token");
await HttpContext.GetTokenAsync("id_token");
). I can also find user claims in HttpContext.User.FindFirst("some claim");
But i have noticed that there is an extra call to the identity server from web api for the userinfo. I observed that it may be because of o.GetClaimsFromUserInfoEndpoint = true;
when i omitted this line i found that user claims are not set, even though i am still getting both id and access token.
So my understanding is the OIDC client of dotnet is using userinfo endpoint to fetch the user claims. But my question is if i am already receiving the access_token why there is an extra call for the userinfo. Can this extra call be prevented?
is there any way so that i receive id_token at first and access_token is then fetched as it is doing now so that same information is not sent twice?
CodePudding user response:
First, you can set this client config in IdentityServer to always include the user claims in the ID token
AlwaysIncludeUserClaimsInIdToken
When requesting both an id token and access token, should the user claims always be added to the id token instead of requiring the client to use the userinfo endpoint. Default is false.
The reason for not including it in the ID-token is that increases the size of the id-token and if you store the tokens in the asp.net session cookie, it also can become pretty big.
I wouldn't worry about the extra request that happens when the user authenticates.