Closed Avery-Dunn closed 1 month ago
I was gonna request something like this too. Would love a way to skip the cache on demand.
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:
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. Marking this is a bug, as it is inconsistent with the other MSALs. Thanks for discovering this.
Related work item: https://github.com/AzureAD/microsoft-authentication-library-for-java/issues/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.~
Fixed as part of https://github.com/AzureAD/microsoft-authentication-library-for-java/pull/811 and released in 1.17.0
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