Scope as part of the cache key? about active-directory-aspnetcore-webapp-openidconnect-v2 HOT 3 CLOSED

There is no need for the scope to be part of the token cache key, because the token saved for that user will be the same but it will contain both scopes. Basically, by the point that the user requested an access token for "scope B", their token will be one containing "scope A" and "scope B".

Does it answer your question?

from active-directory-aspnetcore-webapp-openidconnect-v2.

Well, I expected that "scope B" would be part of the token, i.e., the scope should not be part of the cache key. The question was more along the line of how it gets to be part of the token? Since we cannot simply edit a token issued by the AD, someone somewhere must request a new token from the AD containing the new scope.

I guess I just wanted to get confirmation, that adding scopes to tokens was indeed taken care of elsewhere (and probably in Microsoft.Identity.Client), and thus was not relevant for the cache key.

from active-directory-aspnetcore-webapp-openidconnect-v2.

@HenningRoigaard . Indeed it's taken care by Azure AD, called by MSAL.NET (which will use AcquireTokenSilent to request a token with a new scope. Note that if the new scope is for the same Web API, this will be completely silent. However if the new scope is for an API where the user has not yet consented, Microsoft.Identity.Web will cause a challenge which will trigger ASP.NET core to prompt the user for consent. When that's done the call will happen again and it will be silent. This is enccapsulated by TokenAcquisition.GetAccessTokenOnBehalfOfUser

from active-directory-aspnetcore-webapp-openidconnect-v2.