Invalid State Error on Ipad safari and chrome

[brajeshk-adappt]

Describe the problem

When logging in with a loginWithRedirect, you will be redirected back to your app with code and state values set as URL query parameters. These values are used by handleRedirectCallback And this result in Error: Invalid state

Environment

Please provide the following:

• Version of auth0-spa-js used: 1.10.0
• Which browsers have you tested in? Ipad "Chrome Mobile iOS 83.0.4103 / iOS 12.0.0", "Mobile Safari 12.0.0 / iOS 12.0.0",
• Which framework are you using, if applicable (Angular, React, etc): "React"

[stevehobbsdev]

@brajeshk-adappt What would really help here is a small reproducible sample that demonstrates the error. Also can you let me know if you're able to reproduce this in the SPA SDK Playground?

This is something we ask on the issue template that you used but unfortunately you have not supplied us with an answer to that question.

[brajeshk-adappt]

@stevehobbsdev
I have clone the repo from "SPA SDK Playground" and follow the steps to run but it's failing while giving "npm start". Please check the below error

Error: Package exports for '/path_to_project/sample/auth0-spa-js/node_modules/nanoid' do not define a valid './non-secure' target
at resolveExportsTarget (internal/modules/cjs/loader.js:614:9)
at applyExports (internal/modules/cjs/loader.js:499:14)
at resolveExports (internal/modules/cjs/loader.js:548:12)
at Function.Module._findPath (internal/modules/cjs/loader.js:650:22)
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:948:27)
at Function.Module._load (internal/modules/cjs/loader.js:854:27)
at Module.require (internal/modules/cjs/loader.js:1023:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object. (/path_to_project/sample/auth0-spa-js/node_modules/rollup-plugin-visualizer/plugin/module-mapper.js:3:28)
at Module._compile (internal/modules/cjs/loader.js:1128:30

[beezital]

I am facing the same issue. Feels like some cookies are not set/retrieved as they should.
Works as expected on Desktop on MacOS (Safari, Chrome, Firefox)
Been trying and comparing with reference auth0-angular-samples 01-Login for days now:

• with version 1.2.4 works
• with version 1.10.0 error
• with version 1.8.2 works

Workaround: revert to version 1.8.2

Note that with version 1.10.0 configuring the angular client with audience (for API calls) and cacheLocation: 'localstorage' still produces the Invalid state error but eventually ends up with a successful login.

Could it be a regression of #186?

[stevehobbsdev]

@beezital Not sure, we haven't change anything in that area for a while for it to be a regression. I'll ask you as well to try and provide a small repro for us to look at, or demonstrate how this can be reproduced using the SDK Playground.

@brajeshk-adappt That's odd - which version of node do you have installed? I have no problems running it in 12.13.1.

[brajeshk-adappt]

@stevehobbsdev I have node v13.3.0 installed.

[thathenderson]

I believe this may be related to the introduction of the SameSite=None cookie attribute in PR 472 for 1.10.0 and this webkit bug. To summarize, Webkit treated cookies with SameSite=None as SameSite=strict, which could end up with the cookie not being written properly.

We recently encountered this exact same issue during testing after our migration from the auth0-js library to auth0-spa-js, and can replicate it consistently in Safari 12 and Chrome 66. Safari 13+ and Chrome 67+ seem to be fine.

According to this Chromium update post, the above webkit bug affects macOS Safari 12 and Safari on iOS 12 (as well as Chrome 51-66).

I'm not sure how to reproduce with the SDK Playground since this only occurs over an https connection (there'd have to be some sort of self-signed certificate situation). A generalized repro method would be to try to write a cookie with SameSite=None in the console of any of the affected browsers and observing that it doesn't get set.

[petermatthews]

A temporary workaround for others struggling with this issue under the affected browsers is to issue a subsequent call to getTokenSilently in the rejection handler for handleRedirectCallback. This will succeed in the general case given the user will have successfully logged in to the auth domain before the redirect back to your app occurs. I'm on the same team as @thathenderson above and this approach has proven successful for us in testing thus far.

A more permanent solution would be greatly appreciated. On the face of things it seems like accommodating Chrome 84's SameSite cookie enforcement behavior and the SameSite="None" bug in older browsers would require user agent detection but perhaps a more clever solution exists.

[stevehobbsdev]

Thanks for the context here. Looks like we can do something more permanent to exclude those incompatible useragents and just not set the SameSite attribute. Let me evaluate that approach with the team and see if we can get something in place.

[mprevdelta]

We're also experiencing this issue with ios_saf 12, Vue, and auth0 SPA 1.11.0. Downgrading to 1.2.3 (as the example uses) fixes the issue, because it is not setting any values for SameSite on the cookies.

It looks like setting SameSite="lax" in storage.ts does all right. Not sure the ramifications of it but it's supposedly even a little tighter than "none"?

[trevorgk]

We are seeing large numbers of these from users who are locked to older versions of Chrome. Is there anything we can do to mitigate the pain?

Today: 38 unique affected users (95 errors)

11% Chrome 58.0.3029
11% Mobile Safari 12.1.2
11% Chrome 84.0.4147
11% Chrome 63.0.3239
8% Chrome 65.0.3325

[bfwg]

Running into the same issue. Any updates?

[adamjmcgrath]

Hi all, we're actively working on this issue and we'll have a fix shortly.

The affected user agents are listed here: https://www.chromium.org/updates/same-site/incompatible-clients

If you need to support any of these, you should use 1.10.0 until we have published a fix.

I'll update this thread as soon as that's the case - thanks for your patience!

[Enngage]

We are seeing this issue as well. Hopefully this can be mitigated soon as it was preventing our users from logging in and we didn't have a clue until now.