We’ve been having some odd issues with our embedded passwordless login. We are switching one of our apps to a new tenant. The reason it’s odd is because we can’t detect any differences between the two tenants yet passwordless (email link) login works on the original tenant but not the new tenant.
The issue shows up when clicking the email login link after starting a passwordless (email link) process. It redirects to a page which shows the following error:
There seems like there is some bad error handling as the whole process is indeed done in the same device and browser.
I’ve seen threads mention that it could be an email provider issue, it seems like some email providers preemptively open links beforehand, but as stated before, it worked on the old tenant. So if it is an email provider issue, wouldn’t both tenants not work? Also, just to note, I’m seeing the same behavior with both outlook and gmail.
Another thread says that turning on the ‘Passwordless OTP’ grant type in application → settings → advanced → grant types fixes the issue, this sounds promising, but that grant type isn’t on in the original tenant either. That being said I’d love to be able to try it regardless of the original tenant, but it’s disabled, and I can’t figure out how to enable it. I’ve read through all the documentation I can find and can’t find a clear way to enable ‘Passwordless OTP’ Does anyone have a clear checklist of what needs to be done to enable that grant type?
I’d also appreciate any other suggestions cause this is driving us nuts. Only thing I can think of is that perhaps the date of the tenant creation might matter? like the feature worked fine on old tenants but is broken on any new tenants. Anyway, we’d appreciate any help we can get.
Thank you for specific problem description and suggestions @jordan.knudsen - I can see your problem.
I checked your tenants, and for further investigation, I assumed you refer to SPA and and /passwordless/start endpoint to receive link via email. But please feel free to correct me at any point if needed, we’ll then have another look on that.
My initial conclusion (to be verified as we work on it together) is that currently Auth0 do not allow for authentication API endpoints being called directly by browser-side generated clients (SPA).
Why I came to this conclusion?
First, please take a look here for security related recommendation for public clients (like SPAs).
Second, when I run the request from within the browser console (and my Auth0 tenant is set with the https://.com* as allowed CrossOrigins URL), I got this:
So the link has not been sent/the flow hasn’t been initiated and it looks like this is blocket by Auth0 server regardless of CrossOrigins policy set in the Auth0 tenant.
Facts:
When I run passwordless/start from outside of the browse (via native Postman), I was able to trigger link being sent to enduser’s email:
But when I click on the link, I receive the same result as you did, and it’s expected as the flow has been initiated outside of browser-based script.
For the SPA, on my newest tenant, I’m also not able to select OTP as a grant flow - this seems to be potentially irrelevant. My bad:( @ryan.madsen please take a look at this thread.
Could I ask you to:
Let me know more about the embedded login form you use? Is the authentication request generated on the browser or backend side?
Which API endpoint you use to initiate the authentication flow?
Did you make this between-tenants comparison for the same app type, authentication grant flow and the same embedded login form?
Further steps: Let’s find out what would work for your specific use case. Thanks!
First, I think it is possible to get the email sent from a SPA as it currently is sending on ours without error. I also attempted to replicate the test you did on google with our client id and url and with ‘https://*.google.com’ in our allowed CrossOrigins. I got the following Error:
But it works without error when I remove the ‘Access-Control-Allow-Origin’ header from the test. I’m don’t think so, but perhaps it’s possible that removing that header makes it act without cors?
Also, kinda odd, but it seems to still send the login email even if it errors. Anyway, regardless it’s currently working on our SPA without error.
To answer your questions:
Our embedded login is a flow we created with our own UI in React. We make the calls manually using the library ‘auth0-js’ specifically the passwordlessStart() call. The call is made on the browser, would it help if we instead made the call from our backend?
see above, I also saw in our console that it’s the same endpoint as the test, /passwordless/start
yes, the comparison was made with all the same, we literally just updated the client_id and url on our site.
Also, even tho OTP grant type isn’t turned on our other tenant, if there’s steps to enable it for this one, I’m down to try it and see if it changes anything, but I have no idea how to enable it. Is it disabled by default for front-end applications?
After connecting all dots, here are my conclusions and recommendations:
It looks like using the implicit grant flow introduced in the passwordless() method within Auth0.js library is not the (default) option for new tenants (like we slowly move away from it.)
Why?
The result of using the implicit grant flow (the one you currently use) for public clients is that various security-related data are being conveyed within the URL (just please take a look at the link the user receives via email with the verification_code)
and if a client-side risk mitigation logic is not applied, then these data may land in the user browser’s history. So these, and the remaining flow related data, are exposed to any attack accessing it. This grant flow was introduced long time ago as given then state of browser and web technologies.
What to do next?
a)You could try to delegate the token acquisition responsibilities to the server side portion of your app code.
b)The other option (recommended for a long term run) is to implement the auth0/auth0-spa-js SDK that embodies the recommended for Public Clients Authorization Code Grant with PKCE (the same flow that native clients use). Step by step guidance available here.
c)Here, on the other hand, is the recommendation for the scenario where the client app and it’s backend resources are served on the same domain.
I hope this was helpful! Please let me know if there are some questions/feedback - happy to discuss it further!
Thanks!
You say it’s not an option anymore, but it still works with one of the tenants? We just verified that it works with our old tenant. When you say it’s not an option anymore, is there a reason that would only be affecting only one tenant?
What do you mean by moving the token acquisition to the server side? I don’t see anything on the management api that allows me to do that. I decided to try to use the authentication api on a quick express server and I have the same issue as before, it works fine on the old tenet, but comes up with the wrong device/browser error on the new one. But I’m guessing that just moving the passwordless/start call to a server is not what you meant?
These are all good/fair questions. I double checked it internally -
For all new tenants, there have been introduced CSRF prevention affecting the behaviour of passwordless with magic links.
However, it can revoked by updating a tenant flag via the Management API as below:
I did the same on my new tenant and the magic link works as normal (so requests can be send from both front and backend)
In case of any further issues / further observations, please reach out so we can collect them and take the needed action!
And thank you for all your checks and feedback!
Sweet, Sounds like a solution that will definitely work. unfortunately, due to constraints we won’t be able to test it immediately, but we’ll update this comment once we do to confirm it worked. Thanks so much for your help Marcelina!
