Auth0 Home Blog Docs

checkSession() returns login_required after login()

login
refresh

#1

I am trying to add ‘keep me logged in’ functionality to my auth0 authentication flow in my SPA. I have an embedded page at app.domain.io/login where the user enters their credentials. When they hit the sign-in button, the app calls the login() method from auth.js, passing in the username and password. If they checked the box, a permission cookie is set to true.

When the user launches the page later, after the token expires, a router guard calls auth0.js’s checkSession() method to get a new token. At this point, checkSession returns a login_required error even after the user logged in with auth0.js’s login() method. If I instead call the authorize() method and have the user log in on the hosted page, checkSession succeeds and does not return a login_required error.

Why does calling the login() method from the embedded page not fulfill the login_required requirement that authorize() fulfills? I suspect this is because checkSession() is meant to work with SSO, and the login() method does not use SSO. However, I want to get this ‘keep me signed in’ functionality working without ever redirecting the user to the hosted auth0 page, is this possible?


#2

I am having the same problem as well. I am using Lock 11.5.2 in a SPA React App. My lock instance looks like:

const lock = new Auth0Lock(
  process.env.AUTH0_CLIENT_ID,
  process.env.AUTH0_DOMAIN,
  {
    auth: {
      redirectUrl: document.location.origin + "/callback",
      responseType: "id_token",
      autoParseHash: false
    },
    autoclose: true
  }
);

Calling checkSession always returns a “login_required” error, even if I do it immediately after completing a login through lock.

Strangely, this only seems to happen on production. When working on localhost, checkSession seems to function as expected.

I’d love some insight as to why this is. Thanks!


#3

Also, I noticed that this behavior only happens in Chrome 65 on Mac OS. Even things to work as expected in Safari.
Chrome 65 was released just a few days ago, so maybe there is a regression here. I seem to remember it was working OK last week.


#5

I tried with Lock in Chrome 65 as the settings used for Lock case were available so I would be a bit more closer to what was used (although there’s still a lot of other settings that can influence this) and I could not reproduce the issue.

The cross origin authentication approach used by both Lock when embedded in the client application or through a custom UI and Auth0.js login method have some limitations (see https://auth0.com/docs/cross-origin-authentication). However, I believe the checkSession method should work correctly as my tests indicate if the authentication also happened with success.

If you can consistently reproduce this you may want to consider sharing an HTTP trace (redact sensitive information like passwords, PII and token signatures or payload). Ideally don’t redact client identifiers as technically this is not confidential information (SPA’s have this available in source code) and that would allow to cross-check the full settings of the client application.


#6

Thanks @jmangelo. I’m no longer seeing this issue. My hunch is that the release of Chrome 65 caused a breakage somewhere, and then someone at Auth0 released a patch that fixed it. Thanks for looking into it!


#7

I ran into the same issue and solved it by tracing all the network requests. Our site is hosted on Netlify with SSL. I believe they redirect HTTP to HTTPS if SSL is configured. Turns out if I requested the site without specifying HTTPS (e.g., www.site.io vs. https://www.site.io), the initial checkSession request would come from HTTP before the redirect to HTTPS. This would cause it to fail with the error “login_required” every time in production. It still worked locally, because all the requests were HTTP. I fixed it by enabling the “Force HTTPS” setting on Netlify.

Kind of a silly problem/solution, but figured I’d post in case someone else comes across the same thing.