First login fails, second login redirects to ".com/null"

[AndrewCraswell]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Browser:

• Edge version: 44.18362.387
• Chrome version XX
• Firefox version XX
• IE version XX
• Safari version XX

Library version

Library version: 1.1.3

Current behavior

Over the last month, users on Edge have been reporting that they get a sort of "double login issue". When presented with the login screen, they choose the account to authenticate with and are redirected back to the app. At this point, they're redirected back to the login page a second time, they choose their account, and are returned to the site correctly on return. However, getting a consistent repro has been problematic.

Today we finally have a user on Edge (one of our offsite vendors) who can consistently repro the issue. Unfortunately, no errors show in the console, and the user was unable to export the network trace HAR as the option was greyed out in Edge browser. They did however take screenshots:
https://i.imgur.com/TjIShD5.png

On the second redirect back to the site, it seems the user is being sent to techskillsforbusiness.com/null rather than the correct redirectUri

The application uses the following configuration for MSAL:

const isIE = () => {
  const ua = window.navigator.userAgent;
  const msie = ua.indexOf('MSIE ') > -1;
  const msie11 = ua.indexOf('Trident/') > -1;

  return msie || msie11;
};

const configuration = {
      auth: {
        authority: 'https://login.microsoftonline.com/common/',
        clientId: process.env.REACT_AUTHENTICATION_CLIENT_ID,
        navigateToLoginRequestUrl: true,
        redirectUri: window.location.origin,
        postLogoutRedirectUri: window.location.origin,
        validateAuthority: true
      },
      cache: {
        cacheLocation: 'sessionStorage',
        storeAuthStateInCookie: isIE()
      }
    },
    parameters: {
      scopes: ['user.read', 'openid', 'profile'],
      prompt: 'select_account'
    },
    type: LoginType.Redirect
}

The redirect to /null is a high priority breaking issue for us which is blocking the launch. As an initial step, I've enabled a logger to get a verbose trace of everything that occurs and will update the bug when the user is able to test again.

With the limited information here, any idea if this is a known issue? Any troubleshooting advice would also be greatly appreciated.

Seems like this could be related to the following issues:
#347 (redirect to /null)
#981 (double login)
#1035 (double login)

Expected behavior

User should be successfully logged in on the first attempt and redirected to the correct redirectUri.

[jasonnutter]

@AndrewCraswell Can you share the steps taken (or conditions that exist) to consistently reproduce the issue? I have heard about this, but I've personally had trouble reproducing it. Thanks!

[jasonnutter]

@AndrewCraswell As a workaround, can you try setting navigateToLoginRequestUrl: false?

[AndrewCraswell]

@AndrewCraswell As a workaround, can you try setting navigateToLoginRequestUrl: false?

We might be able to. At the moment it's necessary as we have different login flows. A user who is registering needs to be redirected back to the registration page to complete their profile while returning users should be redirected to the page that login was initiated from.

Can you share the steps taken (or conditions that exist) to consistently reproduce the issue? I have heard about this, but I've personally had trouble reproducing it. Thanks!

Unfortunately not, I've been unable to repro on my own machine and I've tried various scenarios. But I have seen it happen on a few user's systems. I'm hoping that verbose logging on the user's machine will give more detailed info to help isolate this...

[jasonnutter]

@AndrewCraswell Gotya. I would suggest exploring that in the immediate short-term, until we are able to find the cause (I have a theory, but it may be a little bit until we're able to confirm, fix, and release).

[PraveenVerma17]

We are exactly facing the same issue, started happening recently.
First time login will fail it will again ask for login and second time it will redirect the url to null

[AndrewCraswell]

@PraveenVerma17 are you able to get a consistent repro? Definitely interested in seeing some verbose logs and/or network trace HARs that show the issue happening... If I could just get this repro'ing on my own system I would be debugging it, but I've been reliant on users reporting the issue occasionally.

[PraveenVerma17]

Not consistently, it happens intermittently. My guess its because of
storeAuthStateInCookie: isIE()

we should just hard code the value true
storeAuthStateInCookie: true

should solve the problem.

[AndrewCraswell]

I've already tried that as well. We still had users reporting issues even after a month.

[PraveenVerma17]

I am going to add hack in my application router code
Redirect app from /null -> /

[AndrewCraswell]

I was able to get a network trace HAR and full verbose console output.

I've uploaded both and it's accessible to Microsoft FTEs:
https://microsoft-my.sharepoint.com/:f:/p/andcra/Ejb-8PvMtIVAqBapjcX3VXABPRXx9ErOrRFm1EvI3dAPVQ?e=59ZDxD

Examining the console logs I see a few errors when the user first hits our site. There is an attempt to renew the token, and after about 1 second the user encounters:

[MSAL] Thu, 10 Oct 2019 20:39:07 GMT:1.1.3-Verbose Loading frame has timed out after: 6 seconds for scope user.read openid profile:8d2d6af6-cc94-4b70-a023-1710193e044e
[ERROR] ClientAuthError: Token renewal operation failed due to timeout.

Our code is not handling a timeout issue, so it spits out a long stack trace to the console which can be ignored. At this point the app knows the user is not authenticated, so they're redirected to login. User chooses their account, and are successfully redirected back to the app. At this point, the following is logged:

[MSAL] Thu, 10 Oct 2019 20:39:18 GMT:1.1.3-Info Returned from redirect url
[MSAL] Thu, 10 Oct 2019 20:39:18 GMT:1.1.3-Info Processing the callback from redirect response
[MSAL] Thu, 10 Oct 2019 20:39:18 GMT:1.1.3-Info State status:false; Request type:undefined
[MSAL] Thu, 10 Oct 2019 20:39:18 GMT:1.1.3-Error State Mismatch.Expected State: null,Actual State: 46b06a2f-d316-4483-8e4a-40ac94ffd62e

App thinks user is still not authenticated, so again they get redirected to the login page. This time it's successful and the state matches so the app knows the user is authenticated.

[AndrewCraswell]

Seems like the double login issue is related to the IdToken renewal failing, which is something we had been considering. Any ideas for manually expiring the IdToken so can try to debug this scenario with consistent behavior? I know we can apply an offset for access tokens, but I'm not aware of anything similar for IdTokens...

[jasonnutter]

@AndrewCraswell Thank you for that information, that is very helpful, as we're aware of timeout issues from STS relating to retrieving/renewing tokens. And I'll find out about manually expiring idTokens and get back to you.

[AndrewCraswell]

Thanks @jasonnutter I'm interested to understand better about the STS timeout issue... Is there a better way we should be handling this to prevent the double login? Or do you think these are separate issues that might be getting conflated? Trying to figure out if there's a hack or workaround that can be done on our side since we're getting more escalations.

[jasonnutter]

For those with this issue, please try msal@1.2.0-beta.1, which contains a fix (if msal is unable to load the correct redirect uri, it will redirect your app to your home page, instead of /null). As noted above, if this is not acceptable for your use case, I recommend setting navigateToLoginRequestUrl to false. We'll continue to investigate the root cause, but this should be acceptable in the interest of not completely break your app. Any feedback is appreciated.

@AndrewCraswell We're working now to better understand the root cause of the timeouts (there's another MSFT team that is also experiencing them at an unacceptable rate). I do think they are related, based on what I've seen so far.

[anton-gorbikov]

@AndrewCraswell do you know, whether users that are facing the issue with double navigation + /null navigation are using Edge's InPrivate mode? Because I see the exact same behavior in this mode in Edge. I've debugged the issue a bit and it looks to me that Edge in InPrivate mode clears up the localStorage/sessionStorage when it leaves the domain, so in our case each time a redirect to login page appears the application's cache is dropped.

As result when you are navigated back to the application the msal.login.request record is removed from the storage, and MSAL have no idea how to navigate you back.

For me changing the storage type to localStorage (fixed double login in my case) and enabling storing in cookies (fixes /null navigation) fixed the situation:

cache: {
	cacheLocation: 'localStorage',
	storeAuthStateInCookie: true
},

[AndrewCraswell]

This is useful info! Unfortunately we have seen that the users reporting the issue are not using InPrivate, and we've started using a cookie for all users so as to make troubleshooting easier.

I do think that people who encounter such issues should check that (a) their cache is not being cleared, and (b) if there are any token renewal timeouts. Both could cause the issue Being described.

Might be more useful to rename this issue since the error logs point to token renewal timeouts being one of the root causes.

[jasonnutter]

@anton-gorbikov Unfortunately, that is known behavior with Edge InPrivate: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13861050/

The workarounds you mention, as well as putting your authority and web application domains in the same security zone, are our recommended mitigation at this time.

[DarylThayil]

@jasonnutter is this resolved

[DarylThayil]

@AndrewCraswell can you confirm the things we talked about last week have resolved this issue for you?

[AndrewCraswell]

@DarylThayil Can confirm that the redirect to /null is no longer occurring, thanks to a PR that Jason merged. Still are seeing occasional state mismatch errors, but I would be more comfortable addressing those when we get a consistent repro. Let's go ahead and close this, and when we have some more concrete examples of the issue I'll file something new.

Btw we took some action items from our discussion last week regarding Id Token renewal timeouts. Just pushed some changes using Access Token against our APIs with custom scope. I will be monitoring our App Insights to see if timeout errors continue, but so far results are positive. Thanks again for the help!

[DarylThayil]

thanks @AndrewCraswell
closing this ticket, this is currently in a beta release, but will be available on the next main pipeline release for people watching / finding this thread.