Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to 'Keep me signed in' after browser is reopened #941

Closed
ritmos opened this issue Aug 21, 2019 · 15 comments
Closed

Unable to 'Keep me signed in' after browser is reopened #941

ritmos opened this issue Aug 21, 2019 · 15 comments
Assignees
Labels
question Customer is asking for a clarification, use case or information.

Comments

@ritmos
Copy link

ritmos commented Aug 21, 2019

I'm submitting a...


[ ] 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:

Browser:

any

Library version

any

Current behavior

  • I set the cache.cacheLocation to 'localStorage' on the UserAgentApplication configuration parameter
  • Log In (No KMSI message displayed)
  • Use the application normaly
  • Close the browser
  • Reopen the browser and try to use acquireTokenSilent to get a new token
    I get error.ErrorCode = 'login_required'

Expected behavior

  • I set the cache.cacheLocation to 'localStorage' on the UserAgentApplication configuration parameter
  • Log In + see the KMSI message and accept it
  • Use the application normaly
  • Close the browser
  • Reopen the browser and try to use acquireTokenSilent to get a new token
  • Get a new valid token

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?

@jasonnutter jasonnutter added the question Customer is asking for a clarification, use case or information. label Aug 22, 2019
@DarylThayil
Copy link
Contributor

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?

@DarylThayil DarylThayil self-assigned this Aug 23, 2019
@ritmos
Copy link
Author

ritmos commented Aug 23, 2019

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 ?

@ritmos
Copy link
Author

ritmos commented Aug 23, 2019

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.

@natalieethell
Copy link

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

@DarylThayil
Copy link
Contributor

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 DarylThayil added this to the September 2019 milestone Aug 27, 2019
@natalieethell
Copy link

@DarylThayil Yes, definitely. Feel free to reach out when you'd like the repro.

@ritmos
Copy link
Author

ritmos commented Sep 9, 2019

@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.

@DarylThayil
Copy link
Contributor

@jasonnutter can you treat this as the next highest prio after you close on ie11 / perf

@jasonnutter
Copy link
Contributor

@natalieethell @ritmos If you can please provide a sample app that demos the issue, that would be appreciated! janutter@microsoft.com if you don't want to share publicly, thanks!

@ritmos
Copy link
Author

ritmos commented Sep 10, 2019

@jasonnutter You have an email with the details. Thanks a lot for your support!

@ritmos
Copy link
Author

ritmos commented Sep 11, 2019

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

@ritmos
Copy link
Author

ritmos commented Sep 12, 2019

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.

@DarylThayil
Copy link
Contributor

@ritmos thanks I reached out to the server team for guidance!

@jasonnutter
Copy link
Contributor

jasonnutter commented Sep 13, 2019

To summarize, there were two issues that we found:

  1. When you make a request to login, you can include scopes from different resources, e.g. a Graph scope and custom scope for your app. However, since access tokens are issued per resource, when calling 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).
  2. We noticed that the "Keep me signed in" control was not appearing as expected in certain situations, which we are investigating.

@jasonnutter
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Customer is asking for a clarification, use case or information.
Projects
None yet
Development

No branches or pull requests

4 participants