[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Other... Please describe:
any
any
Why can I set the storage location to a permanent one (localStorage) and not continue with the last session if the browser is closed? Also on that regard, I'm not getting any KMSI checkbox during the login process. What am I doing wrong?
this sounds like a bug, can you inspect the localStorage cache and see if it contains an idtoken after reopening?
Another option is to call msal.getAccount() to see if a user is in context
Can you also try opening another tab after being logged in and let me know if you are logged in on the tab?
That's the thing: msal.idtoken is there, at localStorage. msal.getAccount() returns an user (which is why my application tries to get a token). But what I get is an error:
AADSTS50058: A silent sign-in request was sent but none of the currently signed in user(s) match the requested login hint.
Trace ID: 24fd63d4-ab82-451e-ba09-3b1dfd723c00
Correlation ID: 0365ee8b-90b9-4390-abf8-939fbab26dfc
Timestamp: 2019-08-23 21:07:52Z
I tried to set login_hint obtaining the same result but it should not make a difference since Msal sets that automatically to the same user (in ServerRequestParameters.addHintParameters).
Any clue ?
Sorry I forgot to answer your last question. While the browser is open, everything is fine. I can open tabs with my app and every tab gets tokens. If the browser is completely closed, this issue appears.
We're seeing the same issue with the token not being cached. We're also setting cache.cacheLocation to 'localStorage', but see a new token being fetched on every acquireTokenSilent call. @Rajeev-K @KevinTCoughlin
Seems like an issue we will need to resolve soon, putting this in our September 2019 milestone. @ritmos / @natalieethell would we be able to reach out to you for repro when we take this work up?
@DarylThayil Yes, definitely. Feel free to reach out when you'd like the repro.
@DarylThayil Sure! We have some big clients waiting for this to be fixed. I can provide you a sample project or access to the real application.
@jasonnutter can you treat this as the next highest prio after you close on ie11 / perf
@natalieethell @ritmos If you can please provide a sample app that demos the issue, that would be appreciated! [email protected] if you don't want to share publicly, thanks!
@jasonnutter You have an email with the details. Thanks a lot for your support!
More details of the issue:
When browsing login.microsoftonline.com directly instead of the redirection url generated by msal.js I can see the KMSI message https://imgur.com/a/XFG4h4v
Why when using msal.js I don't see such message? For me it's mandatory to get the permanent cookie when login in in order to have the application properly working for many customers
Ok, I think I got the cause of not seeing 'Do you want to keep the session open?' message (KMSI).
For some reason, login.microsoftonline.com behaves different if the login URL contains the x-client-Ver=1.1.3 query string. Because if I remove this item from the URL generated by msal.js (UrlUtils.ts:56) I get a proper login flow with the 'keep me signed in question' I set in AzureAD settings.
I don't know if the 'bug' is in msal.js library, in the microsftonline endpoint or in both, but at this point I'm gonna use a custom 'patched' msal.js by removing this item from the URL generated.
I have provided you the tests scenarios by email.
@ritmos thanks I reached out to the server team for guidance!
To summarize, there were two issues that we found:
acquireTokenSilent, you must make a separate call to get the token for each resource. If you attempt to call acquireTokenSilent with scopes from different resources, that will always result in a cache miss, as we don't cache tokens that way (because there will be multiple tokens, one for each resource). This will result is a network call to get a new token, which will also result in an error. The fix here is to ensure that you call acquireTokenSilent for each resource (with the scopes for that resource and the correct authority).I have reached out to the team responsible for the login UI to investigate the potential issues with the "Keep me signed in" control.
Closing, as no further actionable items.
Most helpful comment
Seems like an issue we will need to resolve soon, putting this in our September 2019 milestone. @ritmos / @natalieethell would we be able to reach out to you for repro when we take this work up?