You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 30, 2023. It is now read-only.
Which platform has the issue?
Android, possibly iOS (?)
What authentication flow has the issue?
Other: AcquireTokenInternactive + AcquireTokenSilent via broker
Repro
AcquireTokenInteractive resource1 (via broker) Actual: adds an AT and IdT to the cache, but the RT (which is an MRRT) is stored by the broker. This is expected.
AcquireTokenSilent resource2 (via broker) - a silent broker calls is happening, but the original AT is deleted
Look at the token cache.
Expected behavior
The token cache should still contain the AT obtained from step1
Actual behavior
The token cache deletes the AT obtained from step1
User Impact
The impact is not significant because the logic falls back to a silent broker call will also produce a token. However this is slower than fetching the result from the token cache.
Which Version of ADAL are you using ?
Note that to get help, you need to run the latest preview or non-preview version
For MSAL, please log issues to https://github.com/AzureAD/microsoft-authentication-library-for-dotnet
latest
Which platform has the issue?
Android, possibly iOS (?)
What authentication flow has the issue?
Other: AcquireTokenInternactive + AcquireTokenSilent via broker
Repro
AcquireTokenInteractive resource1 (via broker)
Actual: adds an AT and IdT to the cache, but the RT (which is an MRRT) is stored by the broker. This is expected.
AcquireTokenSilent resource2 (via broker) - a silent broker calls is happening, but the original AT is deleted
Look at the token cache.
Expected behavior
The token cache should still contain the AT obtained from step1
Actual behavior
The token cache deletes the AT obtained from step1
User Impact
The impact is not significant because the logic falls back to a silent broker call will also produce a token. However this is slower than fetching the result from the token cache.
What is actually happening
a. The tokenCache holds an entry, but this entry is not resource specific and no MRRT exists because borkers hold onto the MRRT
b. The tokenCache continues to look at the original AT
c. The tokenCache continues to think there is an MRRT available locally
d. The token cache deletes the original AT because it thinks it is old
The text was updated successfully, but these errors were encountered: