Force a token refresh when claims are part of a silent request

[Avery-Dunn]

Currently MSAL Java will return a cached token even if the request has some non-empty claims. The request could be expecting an access token with different claims than the one that was cached, leading to a new claims challenge when the token is used.

To avoid this, the silent flow behavior should match the behavior in MSAL .NET, which is to force a refresh if there are claims in the request: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/src/client/Microsoft.Identity.Client/Internal/Requests/Silent/CacheSilentStrategy.cs#L47

[crimsonvspurple]

I was gonna request something like this too. Would love a way to skip the cache on demand.

[Avery-Dunn]

Hello @crimsonvspurple : This is for a specific case where an access token may have been invalidated so the cached one might have the wrong claims, and the acquireTokenSilently API can/should handle it. Is that the same scenario you're working with, or is there some other scenario where you'd want the silent flow to skip the cache?

Because when using any other acquireToken API that isn't acquireTokenSilently, you should already be able to skip the cache:

• For some confidential client applications we automatically try to return a cached token: if you're acquiring the tokens using the on-behalf-of or client credential flows there is a 'skipCache' flag that you can use to bypass the cache.
• For other confidential client flows and all public client flows (username/password, device code, etc.) we don't try to return a cached token automatically, so you can always skip the cache by simply not using the acquireTokenSilently API.. So only acquireTokenSilently, acquire token on behalf of and acquire token for client need to be modified with "force refresh". Using a cache is very important, ESTS will throttle apps that request tokens too often.

[bgavrilMS]

Marking this is a bug, as it is inconsistent with the other MSALs. Thanks for discovering this.

Related work item: #757 (should be done together, as the other one has advanced test cases).

Normally this would be a P1 as it blocks 2 important scenarios (claim injection and CAE), but there is a workaround with "force refresh" so marking as P2.