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

Login (autologin) behaviour is not consistent across browsers. #140

Closed
augustosamame opened this issue Oct 25, 2020 · 5 comments
Closed

Comments

@augustosamame
Copy link

augustosamame commented Oct 25, 2020

Describe the problem

Login (autologin) behaviour is not consistent across browsers.
I have setup 2 sister domains, each pointing to the same auth0.com tenant and sharing the same connection.

domain1:
sso1.starsona.com

domain2:
starsonafans.net

They are both running the same (latest) version of the React SDK sample project.

Behaviour in Firefox:
user is logged out in both domains
user clicks on login button in domain1 and gets redirected to auth0 auth url
user signs in
user gets redirected back to domain1
REFRESHING or NAVIGATING to domain 2 with user logged in domain 1 will open the page with user AUTOMATICALLY LOGGED IN in domain 2
This is the expected, correct behaviour and why we're using Auth0 for SSO in the first place.

Behaviour in Chrome (including mobile version) and Safari (including mobile version)
user is logged out in both domains
user clicks on login button in domain1 and gets redirected to auth0 auth url
user signs in
user gets redirected back to domain1
REFRESHING or NAVIGATING to domain 2 with user logged in domain 1 will open the domain2 page with Login button visible (user is NOT AUTOMATICALLY LOGGED IN in domain 2).
Clicking on Login button will login user without having to type in credentials again.

This is unexpected, and confusing to the user. If user is logged in, why is an extra click needed for logged in state to be shown?

What was the expected behavior?
Login should work consistently across browsers

Reproduction
Detail the steps taken to reproduce this error, and whether this issue can be reproduced consistently or if it is intermittent.
Note: If clear, reproducable steps or the smallest sample app demonstrating misbehavior cannot be provided, we may not be able to follow up on this bug report.

We cloned the auth0-react project and have not modified it at all, except for adding the appropriate settings in auth_config.json

{
"domain": "starsona.us.auth0.com",
"clientId": "C7KpWJOGVf5E3UPrUc9LRNmJsaDjgRfw",
"audience": "https://starsona.us.auth0.com/api/v2/"
}

Can the behavior be reproduced using the React SDK Playground?

it's an unmodified copy of the repo.
we have deployed this project to https://starsonafans.net/ and https://sso1.starsona.com
where the issue can be replicated with ease.

Environment
Version of auth0-react used:
master branch as of today

Which browsers have you tested in?
Chrome Version 86.0.4240.111
Firefox 81.02
Safari Version 14.0 (15610.1.28.1.9, 15610)

Which framework are you using, if applicable (Angular, React, etc):
React

@frederikprijck
Copy link
Member

frederikprijck commented Oct 26, 2020

Hey @augustosamame ,

I tried reproducing this in Firefox 81 and Chrome 86, but I get the exact same behavior in both browsers.
I tested this both using 2 localhost instances as well as on your domains.

In both cases, the second domain shows the login button while the first domain is logged in (so I see the behavior that you are seeing in both browsers).

The reason this is the case is The React SDK Auth0 is not set up to check any cross domain SSO session on load by default.
In general, I think there are a few ways you can approach this but the main idea is that you want to check authentication on page load.

@adamjmcgrath @stevehobbsdev I think we might want to consider exposing the SPA's checkSession as part of the React SDK?

Is there also any reason why the ReactSDK does not use the SPA's createAuth0Client, which would incorporate a call to checkSession and would allow for cross-domain SSO without any custom development from the user.

SPA JS: https://github.com/auth0/auth0-spa-js/blob/master/src/index.ts#L22
React SDK: https://github.com/auth0/auth0-react/blob/master/src/auth0-provider.tsx#L190

checkSession is configured to only check the session if auth0.is.authenticated is set to true, which means it does not work cross domain unless that value is set to true in local storage: https://github.com/auth0/auth0-spa-js/blob/master/src/Auth0Client.ts#L556.

@adamjmcgrath or @stevehobbsdev would you have more information on whether or not this is expected ?

@stevehobbsdev
Copy link
Contributor

Yes the issue being reported is unfortunately expected. We make use of a cookie as an optimization to determine whether you might be logged in or not, and only silently login on startup if that cookie is present and its value is set to true.

This logic is checked by checkSession, which is what auth0-react checks on startup. A workaround here as @frederikprijck suggested above should work - call getAccessTokenSilently on startup and handle errors (particularly login_required). Although I'm not sure if there's anything additional we'd have to do here to refresh the authenticated state within the app - what do you think, @adamjmcgrath?

@adamjmcgrath
Copy link
Contributor

Although I'm not sure if there's anything additional we'd have to do here to refresh the authenticated state within the app - what do you think, @adamjmcgrath?

Yep - The work I'm planning to do to resolve #109 will enable you to use @frederikprijck's suggestion

@augustosamame
Copy link
Author

Thank you for jumping on this. So bottom line, do I need to do additional work on my end to get the desired behaviour? Or do I have to wait until #109 is resolved? I notice it's been open for a couple of months. Any updated ETA on it? I'm working on integrating our project with Auth0 as we speak so I would like some clarity on the best way forward.

@adamjmcgrath
Copy link
Contributor

Hey @augustosamame - yep, you'd need to wait until #109 is resolved then do getAccessTokenSilently on page load.

I'm planning on raising a PR for #109 this week or next, will close this in favour of #109

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants