Big inconsistency in API for passwordless


I am using passwordless to authenticate users in a mobile app.

Using /oauth/token with grant_type=password, one is able to use a passwordless username/password with a default_directory.
However, using grant_type=, one is not allowed to use realm sms/email… How consistent is that ? That restricts us using passwordless either with sms or email but not both…

I know the official guide-line is to push toward universal-login, but in case of a native mobile app, this is a really poor user experience and a no go for our business case…

Could anyone argue why there is this restriction ? And saying that there is “no support” for it doesn’t seem to me like a valid argument. I expect from a company offering security services a robust, full-thought api and not an api offering half features and allowing “unsupported cases”…
For consistency one should allow grant_type= to work with sms/email or disallow using grant_type=password with passwordless (which would probably break a lot of applications including ours).

Hi Jonas,
I’m having the same problem.
I did get email working and documented it here:

Sad to say, we can’t just update the “connection” attribute on both requests to “sms”, that is what I expected though.

Maybe someone can help us, and update the documentation for passwordless for once?
@konrad.sopala @nicolas_sabena @James.Morrison

The response I’m now getting is:

    "error": "invalid_request",
    "error_description": "Passwordless authentication is not allowed on this endpoint."

That is on a request to : https://*****
With password-realm and connection = sms.

Some help would be appreciated…

Hi Nico,

No, I couldn’t find a solution because there is none… Passwordless is not officially supported for direct authentication… One is supposed to use the universal login with redirection on auth0’s website…

We currently dropped support for email in our app and only rely on sms… This is a big shame and as it is not officially supported, the workaround with default directory (allowing only one connection sms versus email) could be removed anytime, leaving us in a very bad situation…

I very much regret this decision and my team and I are thinking about an alternative to Auth0 to address this problem.

Here are the posts I found saying this explicitly:

Hi Jonas.

Like you said, passwordless authentication using the resource owner password grant is not something that is supported at this moment. The fact that it works with a default directory is more of an unintended consequence (and, like you said, it might break at some point), but passwordless authentication as it stands today was not designed to work with /oauth/token.

I wouldn’t say that “unsupported” is a valid argument for the restriction, it’s just the way it is at this moment. The real argument is prioritization. Auth0 is a big product, offering many features, and there are many new great things coming up in the pipeline. As with any software product, feature development is prioritized against other features, fixes and improvements in the backlog, weighing resources available, value added, impact on customers, and so on.

I encourage you to leave feedback at Auth0: Secure access for everyone. But not just anyone., explaining your use case and why universal login doesn’t work for you. This feedback reaches the Product team directly for analysis.


So to be blunt… what you’re saying is… If we want passwordless directly in our native app, we need to look for an other provider than Auth0?

There’s no magic workaround that I can provide. This is something that needs to be implemented (i.e. it’s not part of the current feature set). You can voice your feedback at Auth0: Secure access for everyone. But not just anyone., so that the product team knows about your needs and takes that into consideration when it’s time to define priorities for the engineering teams.

Hi Jonas,

I’m curious to know which alternatives to Auth0 you are been considering for implementing passwordless. Maybe we can get in touch outside of this forum?



This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.