This repository is for active development of the Azure SDK for JavaScript (NodeJS & Browser). For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/javascript/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-js.
MIT License
2.09k
stars
1.2k
forks
source link
Identity: Unable to log into multiple accounts using the Token Cache #28896
Describe the bug
I am developing a VSCode extension and try to use Microsoft Graph to access Outlook resources of two different Microsoft accounts and cache the tokens using the @azure/identity-cache-persistence package (v1.0.0) and the InteractiveBrowserCredential.
With the token cache enabled, I can log into the first account (the browser opens) and give access to an OAuth application to some Outlook resources. I do this by manually calling authenticationRecord = credential.authenticate(...)
Since this is the first log in, no AuthenticationRecord can be provided to the InteractiveBrowserCredential.
Now I try to log into the second account (by setting InteractiveBrowserCredential.loginHint to another value) and again without providing any AuthenticationRecord because it is not available yet. What happens then is that the AuthenticationRecord of the first account is being returned without opening the browser and thus without giving me the chance to log into that second account.
My workaround for now is to disable the token cache when no authentication record is available (i.e. for the first log in) and enable it for all subsequent login attempts. But that leads to the inconvenience that I need to log in twice into every account instead of only once because only for the second log in, the token cache is enabled.
To Reproduce
Below is the code that does not work for me, i.e. the token cache is always enabled. Run it twice with different user accounts (set loginHint to a different account each run). Azure Identity will ask the user only once to log in.
Expected behavior
I expect a possibility to enforce authentication, i.e. ignore the token cache, but at the same time update it when the authentication was successful so it is populated when the user needs to authenticate the next time.
More specifically, I would expect that the token cache is (optionally) bypassed when no AuthenticationRecord is available so that the user is forced to authenticate manually.
Describe the bug I am developing a VSCode extension and try to use Microsoft Graph to access Outlook resources of two different Microsoft accounts and cache the tokens using the
@azure/identity-cache-persistence
package (v1.0.0) and theInteractiveBrowserCredential
.With the token cache enabled, I can log into the first account (the browser opens) and give access to an OAuth application to some Outlook resources. I do this by manually calling
authenticationRecord = credential.authenticate(...)
Since this is the first log in, no
AuthenticationRecord
can be provided to theInteractiveBrowserCredential
.Now I try to log into the second account (by setting
InteractiveBrowserCredential.loginHint
to another value) and again without providing anyAuthenticationRecord
because it is not available yet. What happens then is that theAuthenticationRecord
of the first account is being returned without opening the browser and thus without giving me the chance to log into that second account.My workaround for now is to disable the token cache when no authentication record is available (i.e. for the first log in) and enable it for all subsequent login attempts. But that leads to the inconvenience that I need to log in twice into every account instead of only once because only for the second log in, the token cache is enabled.
To Reproduce Below is the code that does not work for me, i.e. the token cache is always enabled. Run it twice with different user accounts (set
loginHint
to a different account each run). Azure Identity will ask the user only once to log in.Expected behavior I expect a possibility to enforce authentication, i.e. ignore the token cache, but at the same time update it when the authentication was successful so it is populated when the user needs to authenticate the next time.
More specifically, I would expect that the token cache is (optionally) bypassed when no
AuthenticationRecord
is available so that the user is forced to authenticate manually.Screenshots
Additional context