Microsoft-authentication-library-for-js: AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'

[jhwoodward]

We are encountering this issue with a small number of users on IE11.

Everything seems to be fine with our configuration because 99% of our users are not experiencing issues.

However unfortunately a small number of high profile users are unable to log in after receiving this error.

[nehaagrawal]

@jhwoodward can you please tell us what version of library you are using?

[jhwoodward]

@nehaagrawal we are using msal v0.1.5 2018-03-26

[nehaagrawal]

@jhwoodward You didn't mention what api is throwing this error but I am assuming it's acquireTokenSilent(). The acquireTokenSilent uses a hidden iframe with prompt=none which means the user will not be prompted for credentials. This API relies on the session cookie established between the browser and AAD to obtain a new access_token. If your session is expired , this API call will fail and you will have to do an interactive token renewal by calling either acquireTokenPopup or acquireTokenRedirect where you will be asked to enter your credentials again.

[jhwoodward]

@nehaagrawal The error is occurring immediately after they return from the Microsoft sign in page (we are using loginRedirect). acquireTokenSilent is called at this point, after we have the Msal user id. As they've just signed in, it doesn't seem right that the session should have expired.

[nehaagrawal]

@jhwoodward We have never seen this issue. Is it possible for you to share the code snippet that is causing this issue? If you can create a small repo on github and share with us where we can reproduce this, that would be ideal.

[jhwoodward]

@nehaagrawal We can't reproduce it, that's the problem. Its only happening for <1% users

[nehaagrawal]

@jhwoodward It looks like IE is dropping the cookie(x-ms-cpim-transdoes). Can you please confirm if it works locally in your dev env(localhost)? Also please mention your exact IE version where you are seeing this issue and where you are not seeing this issue? I have a feeling that some users are on an older IE version and upgrading the IE version may fix this issue.

[jhwoodward]

@nehaagrawal we can't reproduce it = it works locally. Yes, that could be. Thanks for the suggestion.

[matteobortolazzo]

Hi, I have the same error in Chrome and Firefox after loginRedirect() using acquireTokenSilent().
userAgentApplication.getUser() gives me the right logged user.

[jhwoodward]

Hi @matteobortolazzo. Unfortunately there are a lot of causes for this error. In our case we are only seeing this for <1% of users in IE only on Windows 7.

[matteobortolazzo]

Same code on another PC with the same Win10 and same Chrome work fine. Is it totally random?

[jhwoodward]

It certainly feels like it ! We think the issue we have is to do with IE dropping a cookie, but MS don't know why, as the IE version is up to date.

[bh3605]

Let me get this straight, if the session has expired, calling acquireTokenSilent will not work because it relies on the session to not be expired?

[himadrinath]

@nehaagrawal @rohitnarula7176 i am using it with next.js because of the server side rendering i am saving the token value into cookies and when user revisit the page in my server side i am validating the token from the request cookie and then sending request to my api endpoint. if user delete the session data from dev console and refresh the page i am using acquireTokenSilent to get the user token it works fine.

but sometime if i delete the session data from dev console after i login and close the browser and then reopen the browser and visit the page then i am getting this error

AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'

not in every browser

1. Microsoft Edge - 44.17763.1.0 (not working)
2. Google Chrome - 69.0.3497.100 (working)
3. Opera - 56.0.3051.52 (working)
4. Firefox Quantum - 62.0.3 (not working)
5. Firefox Developer Edition - 64.0b2 (not working)

[RobARichardson]

We're seeing this issue for a very small percentage of our users as well.

• We're using the latest version of msal-angularjs available on NPM (0.1.1) with an AngularJS SPA.
• Chrome is usually the most reliable browser for our application but we're even seeing this error with Chrome.
• As stated above (by others), we haven't been able to reproduce it locally because it's very sporadic.

Steps to reproduce this error appear to be the following:

1. User begins a new session with our application by signing in successfully through B2C using loginPopup.
2. The app attempts to make the first API call using the user's new session but fails due to: AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'

[himadrinath]

@nehaagrawal @rohitnarula7176 @navyasric check out this problem https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/349#issuecomment-431649665

here is the source code for that

https://github.com/himadrinath/next-b2c-redux-auth

[rventuri76]

I have exactly this error only on safari on Mac Version 12.0 (14606.1.36.1.9).
Same code on same Mac but using Chrome works correctly.

I can repro this easly. the only solution I found is to ask password twice with acquireTokenRedirect when acquireTokenSilent fails.

It might has to do with the hidden iframe not working properly on safari....
I finally find out that the issue is related to this settings of safari:
Preferences -> Privacy -> Prevent cross-site tracking

The problem is that this setting is enabled by default. Any idea?

[nehaagrawal]

I saw this solution on a similar thread https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/214
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/214#issuecomment-367668612
Does it work?

[rventuri76]

I saw this already but did not work for us.
I only noticed that changing this setting in safari solves
Preferences -> Privacy -> Prevent cross-site tracking

but I can not ask all customers to do that

[emilverwoerd]

We are currently having the same issue and it appears that it is not possible for IE to send the necessary cookie. The problem in IE is that the cookie ‘x-ms-cpim-sso’ isn’t allowed and their fore it isn’t possible to create a new access token for the end-user. As solution for IE it works when the site ‘xxxx.b2clogin.com’ is in the Local Intranet zone.

I have traced this with fiddler and their you can clearly see that IE when not in the Local Intranet Zone is not allowing the cookie and not refreshing the cookie. This is no problem for Chrome since that will just send the cookie and continue.

[ursmeier-mercatus]

Any update on this?
Same as @rventuri76, our application runs on latest Safari version (>12) only with the disabled setting Preferences -> Privacy -> Prevent cross-site tracking, which is on by default.
Any hint for a workaround is highly appreciated.

[navyasric]

For IE, Edge this seems like the issue related to security zones on the browser. Please try the latest MSAL.js v0.2.4 and set the flag storeAuthStateInCookie as described here: https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/Known-issues-on-IE-and-Edge-Browser#issues

Please note that MSAL.js relies on the cookies being set in the browser for silent token requests. If the browser drops the cookies, the silent calls from the library will fail as expected.

[MaximBalaganskiy]

Just setting storeAuthStateInCookie is not enough. @emilverwoerd 's suggestion works though.

[emilverwoerd]

The problem is that in IE the site Localhost also is in the 'Local Intranet zone' The solution is that both sites the site that is implementing the MSAL library and the B2C are in the some 'Zone' since there is no cookie sharing between the different zones. That is specific for IE

[jeffersoneagley]

+1 We just ran into this too.

[navyasric]

As previously mentioned, the library relies on cookies for a valid user session to be set in the browser. If the browser drops cookies, the silent token acquisition and renewal will fail. The workarounds related to zones suggested in above comments have been documented in the MSAL.js Wiki. Please follow the Known issues on IE and Edge as well as Known issue on Safari for the respective workarounds. Closing this issue.

[ursmeier-mercatus]

@navyasric do you know why ADAL does not have the same problem? Maybe MSAL could use the same approach? Thank you.

[jeffersoneagley]

Well I'm getting this issue on Chrome, so the Edge/safari workarounds aren't going to be much help.

[navyasric]

@ursmeier-mercatus Which ADAL library are you using and what type of app are you building(angular, node.js, etc)? Is your app a B2C app since the error in the above title is a B2C error and msal.js is used for B2C scenarios. Please describe what is the scenario in which you see the error and provide any repro steps or sample.

@jeffersoneagley Please also describe the scenario, type of app and the error message you are seeing. If you can provide repro steps that would help as well.

We can consider reopening this issue(if related) or a separate issue if we get more info.

[ursmeier-mercatus]

I am referring to the Safari "issue" documented in https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/Known-issue-on-Safari

We are using ADAL for the Admin-Users who sign in to their cooperate AD (e.g. company.com).
The End-Users sign in with MSAL into ad ADB2C which is linked to the main AD (company.com).
They share a common database.

The Admin ADAL users can silently renew their tokens with any Safari settings.
The MSal users can silently renew their tokens only when Safari settings "Prevent cross-site tracking" are off (as documented).

ADMIN ADAL App:
angular: 7.0.0
adal-angular4: 3.0.16
tenant:guid-for-ad
USER Msal App:
angular: 7.0.4
azure/msal-angular: 0.1.2
authority: https://login.microsoftonline.com/tfp/<adb2c-name>.onmicrosoft.com/b2c_1_signin/

Since the behavior is documented, I do not create a separate sample, but let me know if you need any other information.

Why is this important for us?
It is impossible to instruct all users on Safari (Mac and iOS) to uncheck security settings. Since it is a default security setting, user don't agree unchecking it anyway. Since ADAL does support these settings, it would be great if Msal could support them as well.

Thank you for any help.

[navyasric]

@ursmeier-mercatus Thank you for sharing the details. The adal-angular4 library is not built and maintained by our team and we cannot comment on that.
The Safari 12 settings that prevent cookies being set by Idps is not always reproducible as they rely on some machine learning to partition. Having said that, we did get reports of the issue on adal.js library as well.
Unfortunately, we currently can only suggest the workarounds. For a more complete solution, we need to evaluate the design and proposals in the industry.

[ursmeier-mercatus]

Thank you, I appreciate your feedback.

[vramasam]

@navyasric

(i) We are also facing below issue very frequently in our project:
client logging : Fri, 01 Mar 2019 04:55:53 GMT:1234-0.2.1-Error Error when acquiring token for scopes: https://tenant_name/user_impersonation AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'.
Correlation ID: 24507434-6c59-47be-a35f-bd2cb0d4171e
Timestamp: 2019-03-01 04:55:50Z
|interaction_required

(ii) Our Project Info:
(1) Project build on Angular 7
(2) We are using the following library:@azure/msal-angular0.1.2 for B2C Communication.

(iii) Root Cause of the issue:
We completely understand the implementation of MSAL library storing the cookie information in the browser. Using the stored cookie info, MSAL is trying to do silent login with this api acquireTokenSilent.

But cookie behaviour differs in browsers:
In Chrome version: If third party cookie is blocked, Chrome loses its ability to store the cookie information.
In latest Safari version(12) : Browser drops the cookie information for security reason.
MSAL login is completely tied up with the browser ability of storing the cookie, is not the best practice. Because slowly browsers start dropping the cookie information for security reason (Like happened in Safari latest version https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/Known-issue-on-Safari) .

(iv) Workaround given by Microsoft:
We know you have given the workaround of showing the login pop up, to the user if silent login fails.

(v) Problem in our project with the workaround
We are handling billing information in our websites.So for security reason we have given 5 mins interval of token active. From end user perspective even if user is actively using the website, showing the login pop up after 5 mins is not acceptable(It's not a expected User experience).And also forcing User to change the browser setting also not a expected user experience.

So we need a proper solution for this ASAP. We have already analysed so many forums and github tickets for this issue. But it will be really helpful, if we get a proper fix(Seamless Silent login without user interaction) for this issue from Microsoft team

[Oceanswave]

Encountering this issue in chrome here as well.

[jeffersoneagley]

Just an FYI, I had previously had this error, and discovered I had some things out of order, but in having to update another part of my UI, I ran into this again.
For starters, this is a valuable function:

/** Is MSAL partway through the auth process? */
export const getIsLoginInProgress = () =>
  !window ||
  !window.msal ||
  window.msal.isCallback(window.location.hash) ||
  window.msal.loginInProgress() ||
  window.msal.getAcquireTokenInProgress();

I'm still hunting for what exactly the cause is, but I remember it being essentially a race condition that happens if your ATS calls happen before MSAL fully finishes loading and such.

[rogerex]

If someone is still getting this issue, please be aware to increment the timeout with enough time to process the load of your page in first login, this step is responsible to save the cachedToken to send later in acquireTokeSilent method, in my case it is working now with non default value (6 seconds)
"loadFrameTimeout": 90000,
Env: Angular v8, @azure/msal-angular 0.1.4, Asp.Net Zero.

[victormasutani]

We're having an issue

AADB2C90077: User does not have an existing session and request prompt parameter has a value of 'None'

after leaving the system idle for a few minutes and starting use it again.

The solution posted by @emilverwoerd worked, however is there any solution that doesn't involve the user change their IE settings?

Env:
@azure/msal-angular 0.1.4
IE 11
Angular v8+

[jasonnutter]

@victormasutani Unfortunately, no.

[sebcam]

i have the same issue on chrome.

[neexs]

I confirm I have the same issue on Chrome too.

Env:
msal 1.2.1
react 16.12
Chrome 80.0.3987.116

[IuliaUngur]

same issue for me with msal 1.2.1 / react 16.12/ chrome 80.0.3987.149. Fixed after I allowed 3rd party cookies on chrome (chrome://settings/content/cookies?search=coo)

[devInterests]

Any news on that? Have users with MacOS and Windows 10 using Chrome and receive the same issue by first token refresh. It seems b2c cookies are not send, but I can see that they are there and not blocked. By other users with same setup everything works fine.

[distantcam]

I've had the same issue using Chrome and this comment https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/349#issuecomment-441986222 by @emilverwoerd helped me figure out a solution.

For local development I had to disable 2 samesite cookie settings in Chrome.
chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

Hope that helps someone else.

[OlegLukash]

This issue started appearing recently in google chrome in incognito mode when I call acquireTokenSilent(). If you work in incognito mode and want to avoid this problem, take attention on start page and don't block third-party cookies. Chrome 83 arrives with redesigned security settings, third-party cookies are blocked in Incognito

[copiltembel]

Yes, but this is not a solution for end-users. You cannot control their browser's settings. If they just enable blocking of third-party cookies, they are simply locked out.

[OlegLukash]

Yes, I agree, for end user this is not a solution. I just wanted to say that default behaviour in Google Chrome in incognito mode recently has changed (in Chrome 83) and this problem started appearing automatically in incognito mode. In other words: we have one more case when this problem appears

[jasonnutter]

MSAL.js v2, currently in public preview, will switch to the Auth Code Flow, which will mitigate issues caused by third-party cookie blocking in most scenarios. See #1000 for more.

[copiltembel]

Yeah, too bad it's not in release yet. Even some of Microsoft's own pages don't work if you don't have 3rd party cookies enabled (ex. I couldn't save in a different location from Word Online on Opera with 3rd party cookies deactivated)

[leandrojj13]

This issue started appearing recently in google chrome in incognito mode when I call acquireTokenSilent(). If you work in incognito mode and want to avoid this problem, take attention on start page and don't block third-party cookies. Chrome 83 arrives with redesigned security settings, third-party cookies are blocked in Incognito

Have you found any practical way to resolve the issue?

[OlegLukash]

@leandrojj13 - Unfortunately not

[eimerreis]

@OlegLukash, @leandrojj13 - you can work around this by handling the error and call acquireTokenRedirect instead.

 try {
   const tokenResponse = this.instance.acquireTokenSilent({
        authority: `${this.config.baseAuthority}${this.config.signinPolicy}`,
        redirectUri: "http://localhost:3000/silent_renew.html",
        scopes: this.config.scopes });
    return tokenResponse;
} catch (err) {
     const error = err as Msal.AuthError;
     // chrome private tab fallback => if acquireTokenSilent fails, we try acquireTokenRedirect method
     if(error.errorMessage.includes("AADB2C90077")) {
         return this.instance.acquireTokenRedirect({
           authority: `${this.config.baseAuthority}${this.config.signinPolicy}`,
           scopes: this.config.scopes,
           state: this.buildRedirectState("/subscriptions")});
      }
}

Since the problem lies in usage of hidden iFrame for chrome private mode