[Bug] "email" scope forces token refresh even if there are valid cached tokens

MSAL 4.7.1 net45

• Desktop / Mobile
  • Interactive
  • Integrated Windows Auth
  • Username Password
  • Device code flow (browserless)

I use the following code to initialize IPublicClientApplication:

var client = PublicClientApplicationBuilder.Create(strClientId).Build();
client.UserTokenCache.EnableSerialization();

Where the implemetnation of UserTokenCache.EnableSerialization() is taken from here: https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization#simple-token-cache-serialization-msal-only

Then I get a token multiple times using this line:

var authResult = await client.AcquireTokenSilent(new string[] {strCustomScope, "email"}, cachedTokenAccount).ExecuteAsync()

I get new tokens every time, even if I have valid (not expired) tokens in the cache. Because of that I get error introduced by this update: https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-breaking-changes#march-2019

Removing “email” scope fixes this and I get tokens from the cache if not expired.

[jmprieur]

@bgavrilMS @henrik-me @jennyf19 @trwalke @neha-bhargava Give it’s external we might want to close it with a link from FAQs ? do you agree?

[rayluo]

IMHO:

1. The current AAD behavior (i.e. not issuing AT for multiple resources) is technically NOT a bug, because the OAuth2 specs allows authorization server to choose a subset of scopes to be fulfilled.
2. The current MSAL behavior (i.e. requesting more scopes than cached token means a cache miss) is not a bug either, because that’s how the scope concept in OAuth2 is supposed to work.
3. Proposing AAD to return an explicit - presumably invalid_scope - error for situation 1 above, would work, in a sense that AAD explicitly disallow the “consenting multiple resources in one interaction” usage. But if that is not the price we want to pay, then AAD and MSAL need to come up with a non-OutOfBand way to convey “hey this is an RT that will work for ALL scopes you just requested”. Perhaps something like this:

Client -> AAD: token request with scope "resource_foo/read resource_bar/write"

AAD -> Client: token response WITHOUT scope parameter, and with RT_for_foo_and_bar,
    with an immediately-expired AT.
    (Here returning an AT to satisfy the OAuth2 specs requirement for an successful response,
    but the AT is immediately expired in  order to
    trigger app developer to use MSAL's AcquireTokenSilent(). See below.)

Client -> ResourceFoo: presenting AT, got an "AT expired" error,
    and then the client would supposedly fall back to AcquireTokenSilent() anyway.
    But we will need to educate the app developer to use scope="resource_foo/read"
    which will then use RT_for_foo_and_bar to acquire a new AT_for_foo.

Client -> ResourceBar:
    Same as above, except the app developer would use scope="resource_bar/write"

From  now on, client will call AcquireTokenSilent(scope= foo or bar), as usual,
and there will always be cache hit.