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

AADSTS50058: A silent sign-in request was sent but no user is signed in. #323

Closed
mpawelski opened this Issue Jun 24, 2016 · 19 comments

Comments

Projects
None yet
@mpawelski
Copy link

mpawelski commented Jun 24, 2016

Hi,
I have simple proof of concept webpage that uses adal.js for sso with azure ad. Everything works fine but I noticed that when I log in, close page, and then come back after very long time I get this error when calling AuthenticationContext.acquireToken:

AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com).

Of course when I log out and log in everything works fine.
I'm using localStorage for cacheLocation.
I open the site in Chrome and Firefox.

When the site load I check if user is sign in with this code

 var user = authContext.getCachedUser();
        if (user) {
            //user is sign in, show "sign out" button that calls "authContext.logOut"
        } else {
            //user is not sign in, show "sign in" button that calls "authContext.login"
        }

I did it as in this Azure AD sample.

Should I check if user is logged in in different way? I don't want to use sessionStorage and have to log in every time I close and open my website

@tushargupta51

This comment has been minimized.

Copy link
Contributor

tushargupta51 commented Jun 24, 2016

@mpawelski Do you check the "Keep Me Signed In" checkbox when logging in the first time?

@mpawelski

This comment has been minimized.

Copy link
Author

mpawelski commented Jul 6, 2016

@tushargupta51 Sorry for not answering that long.

I don't check the "Keep Me Signed In" button. But I don't want to force my users to do it. And even when I don't check it and then close the browser and open the browser again, I am still logged in (I can do authorized API calls).

So my question is:
How to really check if user is logged in (because authContext.getCachedUser() seems to be unreliable as I described in first post)? Should I do some API call to Azure AD to get information if user is really logged in?

@tushargupta51

This comment has been minimized.

Copy link
Contributor

tushargupta51 commented Jul 7, 2016

@mpawelski When user logs in, adal saves the id_token in browser cache. This token expires in 1 hr. Since you are using localStorage, this cache persists when you re-open the browser. So, if you are re-opening the browser within 1 hr of logging in, everything will work fine, as you noticed, since the cached token is valid. But if you re-open the browser after 1 hr, the cached token is expired and adal tries to renew the token but it fails since the AAD authentication cookie is expired or not present and you get the AADSTS50058 error. If you don't check the KMSI checkbox, this cookie is not persistent, meaning when you close the browser, it will be deleted as expected. That is why, token renewal operation fails. From a user perspective, if I don't check the KMSI checkbox, I wouldn't expect myself to be logged in when I re-open the browser.

Assuming you are not using the angular wrapper (as it seems from your code), you can call AuthenticationContext.getCachedToken(clientId) to check if there is a valid id_token or not. Also, in the callback you pass to acquireToken, you can check for this specific error and call login method to redirect the user to log in again.

@mpawelski

This comment has been minimized.

Copy link
Author

mpawelski commented Jul 8, 2016

@tushargupta51 Thank you for you answer! I have a question just be sure:

So the recommended way of checking at beginning of application if user is logged in is to check if return values of AuthenticationContext.getCachedUser(); AND AuthenticationContext.getCachedToken(clientId) are not null?
Is it enough or should I also call acquireToken and check if it won't fail?

I just want to be sure what the recommended way of doing this.

@ChrisSchaller

This comment has been minimized.

Copy link

ChrisSchaller commented Jul 12, 2016

When using the angular wrapper you can legitimately get the AADSTS50058 error exactly as the error description states. For me I have *.microsoftonline.com set as a trusted site, but when debugging locally localhost is not a trusted site, so I added my local host path for this app into trusted sites and it all works again. Be mindful that it is not uncommon for a user to set trust for core MS services, if they have done so then they may not yet have also trusted your deployed site url, so it is important that this runtime error (or one that conveys the same information) is displayed to the user so that they can take the appropriate action.

@evlo

This comment has been minimized.

Copy link

evlo commented Jul 18, 2016

I'm not using angular wrapper, i'm using getCachedUser anad i'm getting this error, both chrome and IE.
I don't really know how to do the login without getCachedUser.

I'm now trying @tushargupta51 suggestion, any idea how to force this error to appear or do i just need to have browser open for day or so?

UPDATE: Error finally appeared for me again and @tushargupta51 with forcing login again when this error happens worked, Yay!

UPDATE2: it worked for me, but my test user is stuck with AADSTS50058 and login loop ...

@tushargupta51

This comment has been minimized.

Copy link
Contributor

tushargupta51 commented Jul 20, 2016

@mpawelski @evlo Ensuring the getCachedToken returns a non null token should be a good indicator of user is still logged in. But please note that if you re-open the browser within 1 hr, getCachedToken will return a valid token, but any acquireToken call will still fail as there is no AAD cookie to use to renew the token. So, making an acquireToken call, and checking for the error code in the callback, redirecting the user to log back in again should work fine.

@evlo Are you using 1.0.11 bits? Please share more details about the loop. Do you see an error being thrown repeatedly? Sharing some logs will help.

@tushargupta51 tushargupta51 self-assigned this Jul 20, 2016

@evlo

This comment has been minimized.

Copy link

evlo commented Jul 21, 2016

I just updated to 1.0.11 on user testing environment, it seems that there is only one user who end ends in the login loop, he uses IE Edge (but site is Sharepoint online (o365), so it runs in IE10 compatibility).
I tried to open developer console(F12) on his station and IE just crashes, without any error, so i guess his client is somehow broken (I don't have any issues in IE Edge). Even thought he does not have problems with other services.
From the glimpse of console i caught he got AADSTS50058 repeatably:
getCachedUser > acquireToken > [AADSTS50058] >login > getCachedUser > acquireToken > [AADSTS50058] > login > getCachedUser > acquireToken > [AADSTS50058] > login > IE window disappears.
But the console was only visible for split second, so i can't be sure.
For time being i just rule it out as client anomaly and i will let you know if i get reports of the issue when we let application to the wild.

@tushargupta51

This comment has been minimized.

Copy link
Contributor

tushargupta51 commented Aug 5, 2016

I am closing this issue for now. Please use 1.0.11. Let me know if you run into same issue, I will reopen this for discussion.

@gabbsmo

This comment has been minimized.

Copy link

gabbsmo commented Aug 10, 2016

I had a similar issue that was caused by the Disconnect.me Chrome extension. My solution was to whitelist my app and login.microsoftonline.com. If you don't this extension will block cookies set by the login page.

@malay2012

This comment has been minimized.

Copy link

malay2012 commented Nov 7, 2016

Hi tushargupta51,

I am using 1.0.12 and still getting same error after adding -
if (!authContext.getCachedUser() && sessionStorage['adal.error'] == 'login_required') {
authContext.login();
return;
}

please suggest!

@NelsonLamprecht

This comment has been minimized.

Copy link

NelsonLamprecht commented Nov 18, 2016

Based on this:

https://support.microsoft.com/en-us/kb/2507767
I added the sites as well as our web app domain to the intranet and trusted zones and the problem went away. The problem never was visible in Chrome since it is unaware of the zone details

@jbranders

This comment has been minimized.

Copy link

jbranders commented Jan 12, 2017

Can someone give me the steps to solve this issue? Still getting the same issue.
Thank you!

@AaronRM

This comment has been minimized.

Copy link

AaronRM commented Feb 1, 2017

Similar to @gabbsmo, I hit this with Chrome + the Privacy Badger extension (it was blocking cookies from login.microsoftonline.com).

@Hongbo-Miao

This comment has been minimized.

@sandeepb6

This comment has been minimized.

Copy link

sandeepb6 commented Nov 29, 2017

@tushargupta51 did u finalized anything. about this issue.

In my case, few users getting this error, We did some workaround to fix this issue like added the login.microsoftonline.com and site url to the trusted sites. In my case when i browse the site login page will not come in IE and Edge as it is authenticated through system credentials.

Is forceful login is a good approach or not? am not sure here.
What should be the action to be take to fix this issue .?
Need help.

@MarkHerhold

This comment has been minimized.

Copy link

MarkHerhold commented Jun 21, 2018

In my case, we had a user whose browser (Chrome) had 3rd party cookies disabled causing the user to have to login again every hour. The issue was fixed by allowing 3rd party cookies.

I hope this helps someone.

@stela

This comment has been minimized.

Copy link

stela commented Sep 5, 2018

Somewhat different use case, but I got the error not in the browser but when a backend service (OAuth 2.0 client) attempts to perform the on-behalf-of flow to trade in an id_token for an access token for the graph API. I'm not using the adal library but just follow the AAD v2.0 on-behalf-of flow documentation.

{"error":"invalid_grant","error_description":"AADSTS50058: A silent sign-in request was sent but no user is signed in. ...","error_codes":[50058], ...}

I only get the error message when using "work"-type accounts, my personal hotmail account works fine. Since the back-end app is hosted on a different domain I doubt if it's possible to include any extra cookies in the request. Checking the stay-logged-in checkbox doesn't seem to help.

I send users to login at
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=...&response_type=id_token+code&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=openid%20https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read&response_mode=fragment&state=12345&nonce=678910

@dalejo09

This comment has been minimized.

Copy link

dalejo09 commented Feb 21, 2019

I think I resolved the problem on "Internet Explorer", this issue is because "https://login.microsoftonline.com" is not added to "IE security zone", so the error says: "the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint"

Steps:
On IE, open "Internet Options" and you have to ensure both sites are on the same security zones "https://{tenant}.sharepoint.com" and "https://login.microsoftonline.com", after that close all sessions and restart it

It worked for me!
Diego A. Campo
diegoc@e-deas.com.co

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.