checkSession() returns login_required just after login() was successful

Hello
I am using Universal Login flow. On production, when the user logs in and gets redirected back, a checkSession poll works fine. Same code on localhost doesn’t work. On localhost, immediately after a successful login and redirection callback, when I try checksession(), it says login_required.

Note the code is exactly the same with one difference i.e. I am using a different tenant and a different client application on localhost.

When I use production’s tenant domain and client ID on localhost, everything works fine again and checkSession call succeeds.

I have checked word by word every field/configuration for the two tenants and applications and I am still unable to spot any difference between the two. What could possibly be going wrong here?

Hey there @sidle.marketing! Are you seeing any errors in the logs or console when the failure occurs? Thanks!

I have the same, but only on Safari 12, are you using Safari 12?

@James.Morrison Here’s the error message

{
    error: "login_required",
    error_description: "Login required"
}

For ease of debugging, I have got two version of applications running now.

  1. Working checkSession at https://d1c.emailyard.com
  2. Broken checkSession at https://d2c.emailyard.com

The code and methods used to build and deploy are exactly the same. The only difference is the following constants in dot env files. I will share it below

For D1 environment,

REACT_APP_AUTH0_DOMAIN=emailyard.auth0.com
REACT_APP_AUTH0_EY_CLIENT_ID=N_Q62V2zXoiF5WZIPa7GDAHYZNB9T2T2

For D2 environment

REACT_APP_AUTH0_DOMAIN=eylocalhost.auth0.com
REACT_APP_AUTH0_EY_CLIENT_ID=Ud6laYTVmNWTrNmjwPnh673Tgu7tAOHW

Steps to replicate

  1. Open D2 Link and make sure you have debug console open with preserve log enabled
  2. It will take you to sign up on Auth0’s Universal Login page. Use any method to login.
  3. You will be redirected back and few seconds later, amidst various debug statements you will find the error starting with message checkSession error-ed out. It also logs Auth0’s configuration options and response data with it for further investigation.

If you are trying out both environments, D1 and D2, make sure you are using two separate email address.

Key Findings

There are two network errors that stand out from Auth0’s side of things. When you are trying to log in via the hosting login page for D2, you see the following errors. These are not visible in the logs of hosted login page for D1’s tenant. Also, note the errors are on Hosted Login page and not on this application page.

  1. SSO Data 404

    client.js:772 GET https://eylocalhost.auth0.com/user/ssodata 404
    
  2. Google’s /accounts/SetSID:8 errors out with 404

On top of that, user is asked to login again for D2’s tenant within minutes of login.
If the application sends the user to login again on the hosted login page, (for e.g. when the token is expired or deleted from localstorage), D1’s tenant immediately redirects the user back to the callback URL. Although, D2’s tenant shows login prompt to the user.

My Theory

  1. For D2’s tenant, persistent cookies aren’t being set at Auth0’s end and hence it doesn’t recognize a returning user. This results in
    • failing checkSession
    • login prompt shown again to a user who logged in just a few minutes ago.
  2. There is some configuration mismatch between D1’s and D2’s tenant for my end. This is unlikely as I have tried creating multiple tenants and application with the same configuration and even creating different application within D1’s tenant and error still remains the same. Please help me figure out what I might be missing.

@sjoerdvisscher

I’m facing the issue on Chrome 69.0.3497 and Safari 1.0.13604. Have tried only these two yet.

Let me know if you need more details from my side.

@James.Morrison Did you get a chance to look at this?

I wanted to follow up with you @sidle.marketing after talking with our support team. When you get a minute can you confirm in your browser that third-party cookies are enabled? From there can you also check to make sure you are not using the default Auth0 dev keys? Please let me know if this helps solve the challenge you are facing. Thanks!

Thanks @James.Morrison. I was able to figure out the problem after looking into the “Logs” tab on the Dashboard.

The issue was I was using default Google connector. :man_facepalming: Auth0 logs had a warning about it and on creating a new Google Oauth Client, the problem got solved. This was completely an error on my part. Looking back, a warning about Default Connector on the console might have sped up debugging. Maybe it’s something you can consider. Thanks a lot for your help!

Awesome. I’m glad it all came together!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.