I’m using auth0.js and I was hoping other users could confirm this limitation as I cannot find it documented anywhere.
As nonce checking is now mandatory it appears to that if a user opens the magic link sent to them in a different browser to the one they used to make the sign in request the sign in will fail with a ‘nonce does not match’ error as the newly opened browser will not have the state and nonce stored. Can anyone confirm this is the case?
Just for a bit of background I have a couple of customers with sites that are mainly viewed in the Facebook app browser. As the magic link they receive will always open in another browser it looks like passwordless will no longer be an option for them.
Are these mobile users? Modern email apps open links via in-app browsers - one solution, if it’s available in the email app, is to use the “Open in xxx browser” which would then open it back in the relevant browser and would work.
They are mobile but they are viewing the site in the Facebook app browser. So opening the link in the Facebook app will not be an option for them when they get the email,
The issue is the other way round. They have signed in from Facebook browser and received the email with the magic link. Now the link will open in their phone browser and which will fail the nonce check. I understand the behaviour it is more that I want to confirm that this is a limitation of using passwordless and I haven’t missed something.
So yes, this is a feature of passwordless in order to verify that nothing untoward is happening and that the same device/browser is performing the authentication.
This is actually also a BIG problem for us @jerdog.
We choose to have our users login exclusively via passwordless, but the fact that the browser needs to be the same posses a huge obstacle for many tech-unaware users.
As an example: Many users use Chrome, but when the check their email using outlook and click the login link, the computer’s default browser will open, mostly on IE or Edge.
It’s hard to communicate this to users who are tech unaware to begin with, especially since we chose the passwordless option as something that we could promote specially for this target group so it “just works”.
Although I can understand you concern for security, I think at the very least, there should be an option to deactivate the same browser policy.
I certainly understand the limitations this presents, but for security reasons it is important for state-checking to be in place. At this time we do not have any plans to change how this operates.
This makes passwordless links very hard to use, we already bumped into many issues where email clients have their own browser (e.g. Gmail for Android).
Presumably this doesn’t apply if you do a code instead of a magic link?
Also, are there any workarounds? I saw in another thread that you could supply your own state when initializing the Auth0 object and later supply the same one to the parseHash method, however then I get another error about the nonce not matching
As a side note, This is a major limitation that should be clearly called out in the notes about passwordless so others aren’t surprised by it…
Would like to bump this thread a bit, since the limitation is an inconvenience to a lot of users.
I’d like to point out another user flow where this nonce check fails (although I’m not sure why):
User enters their e-mail and sends a magic link
They now switch Chrome/Google profiles (which opens up a new “instance” of Google Chrome)
Even though they still use the same browser on the same device, the nonce check fails since (I presume) Google keeps cookies and other storage means separate for profiles.
This is a very common scenario for people using both their personal and corporate Google profiles/accounts in Chrome
and has caused us a lot of headache solely because we decided to use auth0 for our auth provider.
This is a similar issue in principle as with Increase inactivity timeout - #6 by jbrinkman,
where auth0 dictates the level of security without compromise for its users, even though it sacrifises the end user’s UX (or even ability to use the login…)
I’d also be interested in an answer to the question @heidi asked - does this check apply to a OTP/code e-mail as well?
Is there any way to work around this? The only option we see atm is to set up our own auth microservice that replicates auth0, but lacks this limitation…
Out-of-the box, Magic links in emails don’t include a nonce as only an access token is requested in the response; an id token response would by default require a nonce, which would have to be generated and applied. state information could also not be verified if two independent browser instances were used.
However an id token can be acquired, and state can be verified, if a silent authentication is subsequently performed as a result of clicking the link (e.g. Auth0.js v9 Reference). If a valid login has been performed, this would basically use SSO to get the login context of the user in a secure fashion without prompting for credentials.
