Failed Silent Auth - Login required

Help
22

@James.Morrison So the instructions say to use the Incognito Tab. However, everything works in Incognito. The problem only happens when not in Incognito. So I’m not sure that recording while in Incognito mode will help!

Please advise.

23

@jkh Investigating. Will keep you posted on what I find.

1 Like
24

@James.Morrison Isn’t there anything you or you collegues can provide us guys which are all having the same problem to find a solution for that? This issue is already open since 22 days

1 Like
25

Right. So the silent authentication issue, the “login required” error, is what you get when your browser does not, or cannot, send the “auth0” cookie. This is the cookie that Auth0 leaves on the browser client once the user has a session with Auth0, i.e. the user has logged in through an interactive flow. You should be able to confirm this by looking at the network logs or analyzing the HAR output. The scenarios that work will have the cookie attached, whereas the ones that fail will not. If that’s the case, this is neither a sample nor SDK issue as they are not involved in the setting of that cookie; it is issued by the authorization server.

If the browser cannot sent this cookie, it’s most likely because of some software or browser extension or something which is blocking third-party tracking cookies. Safari does this by default thanks to its Intelligent Tracking Prevention (ITP2) software that is built-in. This can explain why silent auth works in Chrome’s incognito mode but not in normal mode. If you’re running some extensions, you might want to disable some of them to narrow down which one is preventing the cookie from being sent.

What I can’t readily explain is how it works in Safari’s Private mode, as I thought ITP2 would block such cookies regardless. Let me get some clarity on that.

In any case, this is most likely an issue with browser configuration/software/extensions that is somehow getting in the way of the browser being able to send that cookie, so I would continue your search there.

Having said all of that, this situation is obviously not ideal and rest assured that we are actively working on a solution that will allow you to get around this.

4 Likes
26

That was it! I have Privacy Badger installed in Chrome. I turned it off for auth0, and it works fine now. As far as Safari, is there a way of turning off ITP2?

I agree that it would be better if silent authentication worked even with anti-tracking extensions turned on. This isn’t mean to be tracking software (I hope).

27

PS If this is going to take a while to solve in the general case, it would be really helpful to have this flagged in multiple prominent places. I spent over 10 hrs trying to figure this out.

1 Like
28

Oh shoot, so it is about this warning in Chrome’s console that I have been seeing and ignoring:

A cookie associated with a cross-site resource at https://wikibus.eu.auth0.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at Chrome Platform Status and Chrome Platform Status.

Not caused by an extension after all, which explains why it’s also the same in private mode.

The cookie, which looks like did=TOKEN; Max-Age=157788000; Path=/; Expires=Mon, 25 Nov 2024 14:57:17 GMT; HttpOnly; Secure is blocked by Chrome. Safari does not give any warnings but the cookie is indeed not setting the cookie on the request either.

1 Like
29

SameSite is a different issue but will only come into effect from February 2020 - are you using a preview build of Chrome? We have published some literature about the changes Auth0 is making for SameSite to cover this change, which may help.

1 Like
30

Nope. It’s Version 78.0.3904.108 (Official Build) (64-bit)

31

As far as Safari, is there a way of turning off ITP2?

Preferences > Privacy > Uncheck “Prevent cross-site tracking” (I had to restart the browser for the change to take effect).

This isn’t mean to be tracking software (I hope)

Absolutely not, it’s just that our cookies get caught up in the net that Apple has cast in order to try and prevent those cookies that aim to track you across the web. It’s also worth mentioning that this is not a problem limited to Auth0, either.

1 Like
32

Nope. It’s Version 78.0.3904.108 (Official Build) (64-bit)

I’m unsure then, as the feature isn’t supposed to be switched on by default yet. The Chrome Status page linked to in the warning mentions a feature flag that you can turn on - can you verify that the flag is disabled?

1 Like
33

Both of the SameSite flags were set to Default. Manually switching to Disabled indeed helped.

But indeed, the link says the this will be enabled by default from Chrome 80. Maybe someone at Google inadvertently changed the default setting to early?

34

Hi @tpluscode. I am using the same Chrome browser version. Can you please clarify which two SameSite flags did you switch to Disabled? I switched to Disabled “SameSite by default cookies” and “Enable removing SameSite=None cookies” but it didn’t help. I still see the same warning in both normal and incognito modes of Browser and it still requires to login on each browser refresh.

35

image
image1458×516 77.6 KB

1 Like
36

Thank you. Made these items Disabled but silent auth still failed in both normal and incognito modes of browser.

37

Facing the same issue, in Safari and Chrome both mobile and desktop. And PWA on IOS and Android. This issue is very anoying for the customers, since they need to log in again.

1 Like
38

Facing the same issue, this is the mobile client which was used:
“user_agent”: “Chrome Mobile 79.0.3945 / Android 0.0.0”,

39

Ok, after spending some time on this with various customers / use cases, I can confirm that mostly this issue happens due to Cookies settings:

  1. In one case, relaxing Firefox security settings with regards to cross-domain cookies solved this issue.
  2. With all of the rest of the cases, these were solved after I upgraded to the paid subscription and migrated to the custom domain which is the same where the app is running.
3 Likes
40

Glad you have it working now @auth0z and thanks for sharing that knowledge with the rest of community!

41

EDIT: It looks like my callback URL was not correct, but instead of actually receiving the “Oops something went wrong” page with that error detail, I just received a 403 and had to authenticate again. I’m not sure which of the three attempted suggestions worked (incognito with no extensions, disabling the two flags mentioned, or switching to a custom domain), but I will update if I can narrow that down at all.

EDIT 2: It looks like there may have been two issues, both only viewable in the source of the response to the network request in Chrome dev tools:

  1. For the 403 response to /authorize: the list of callback URLs must, for some reason, include both https://example.com AND https://example.com/callback.
  2. For the 400 response to /authorize: the list of allowed web origins must, for some reason, include both https://example.com AND https://example.com/.

The latter of the two issues was encountered on a tenant that did not have a custom domain, so that solution was likely unnecessary. It is possible that both of these issues were due to configuration problems on my end, but I really think the documentation should be clearer about these things.

1 Like