Auth0-spa-js: [Feature] Support passwordless login

[qortex]

The library does not support passwordless login at this point.

I have this workaround discussed in this other issue, but it is not satisfactory. As it forces to use another "copy" of the auth0.js library object, state is not recognized by auth0-spa-js when it handles the connection back through the usual flow (handleRedirectCallback), issuing an error ("invalid state"). It manages to recover from this error, but this is dirty and it leaves open the question of if this opens a vulnerability in the auth scheme.

I suspect it wouldn't be a huge effort to implement that & test suites for someone who is used to the codebase, based on the snippet I shared?

As the passwordless feature is widely advertised by Auth0 and becoming more and more popular, I'm sure it would make a lot of sense to have first-class support in auth0-spa-js. What do you think?

[qortex]

Looking at this further, I'm not so sure about how auth0-spa-js manages to recover from the failed state. I guess it uses cookies that are also set through the passwordless login.

It seems brittle though, and a secure & bullet-proof way to handle this common scheme would be much appreciated.

Maybe custom code even if it's not included immediately in the library?

Thanks

[stevehobbsdev]

@qortex Thanks for raising and I will in turn raise this internally, as it's a product decision.

A bit of history: one of the reasons this SDK was created was to break out the "authentication" part of Auth0.js into a library in its own right, amongst a few other reasons. At the time we had plans to eventually do the same with the management API and passwordless parts and create modules that encapsulated those features, rather than bundle them all back into this library.

I'm unaware as the status of that work but as I said, I will raise it. I can imagine it being unlikely that it would be integrated here but as you've highlighted, there could be problems with _not_ integrating it into this SDK.

Closing this for now but let's continue the discussion. If I have any news/decisions to share, I will do so here.

[qortex]

Thanks for the explanation.

Indeed, putting the passwordless as part of this library or as a standalone (plugin?) is open. But then really, what is the recommended way to implement passwordless on a SPA with auth0 currently?

I can see Lock, but then you're bound to use the lock UI if I'm not mistaken. It's react and I use angular, I'm not so keen on pulling such dependencies.

Really, I feel adding this flow to this library would be the best way to go. It seems both coherent and necessary to avoid the issues I have ran into. Passwordless should be first-class citizen in the auth0 ecosystem, especially with recent developments around that trend.

I guess it all boils down to Universal Login not supporting passwordless, so it can't be as "clean" as the password flow.

Anyway, maybe a good way to discuss that is to know first, I may be missing something: what is the recommended way to implement passwordless on a SPA with auth0 currently, with my own UI?

[qortex]

The alternative would be for me to not use auth0-spa-js at all and use auth0.js directly. But then it means doing what auth0-spa-js does for pkce. Which at this point defeats the purpose of relying on auth0 to handle bullet-proof auth mechanism - and costs me unbounded number of hours.

How do other SPAs handle this situation? I can't think I'm the only one in this situation :)

[stevehobbsdev]

You're right in that we don't currently have a good passwordless story for JS, but as I mentioned I have raised this for discussion internally and hopefully I can come back with something that may close that gap at least in the future.

The only recommendation I can make at the moment is to use the workaround you described earlier, despite it being less ideal, or use Auth0.js.

[qortex]

Thanks, noted!
Let me know if I can be of any help with beta-testing some exploratory stuff.

[qortex]

@stevehobbsdev Any news on the internal discussion about passwordless login with spa?
Really a show-stopper for seamless login :(

[stevehobbsdev]

I'm afraid to say I don't have anything that I can report at this time.

[smorimoto]

If you all will to support it, leave this open. If not, add a wontfix label. That may confuse many people.

[stevehobbsdev]

Thanks @smorimoto - we have no plans as yet to support passwordless mode in this SDK, and have added wont fix as requested.

[qortex]

:-1:

Do you think it would be possible to get a magic link "ticket" endpoint in the API at least?
Or where should this feature request be posted?

Thanks

[martinblostein]

The README for this project says:

Auth0 helps you to easily:

implement authentication with multiple identity providers, including social (e.g., Google, Facebook, Microsoft, LinkedIn, GitHub, Twitter, etc), or enterprise (e.g., Windows Azure AD, Google Apps, Active Directory, ADFS, SAML, etc.)
log in users with username/password databases, passwordless, or multi-factor authentication

Emphasis mine. While it is technically true that Auth0 (not this SDK) supports a passwordless flow, I think that it's misleading to advertise the passwordless support that Auth0 provides on the README for an Auth0 SDK without noting that the SDK in question does not support that flow, and there are no plans to ever support that flow.

I've spent a while getting Auth0 and this SDK configured and just hit this blocker. It has left a bad taste in my mouth. I suggest that you clearly indicate what parts of Auth0 this SDK supports on the readme page. This will avoid frustrating potential customers of Auth0.

[qortex]

I feel you. It has definitely been a huge time-waster for me in hindsight.
And I have the same taste in my mouth: plain false advertising that bites you by surprise once you have adopted the solution and just want to rollout the feature you planned at trial time and was said to be supported. You could think it would take 2h once the SDK is installed... and it definitely doesn't.

[qortex]

Btw, still badly need the "Login link ticket" API endpoint.