Big inconsistency in API for passwordless

[jonas.lauber]

Hi,

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=http://auth0.com/oauth/grant-type/password-realm, 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=http://auth0.com/oauth/grant-type/password-realm to work with sms/email or disallow using grant_type=password with passwordless (which would probably break a lot of applications including ours).

[n.bijl]

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

Using Passwordless code, through API

We finally found the solution. After some testing and finding this post: http://community.auth0.com/t/how-to-authorize-user-with-email-password-from-server-code/7239 Steps to implement: Request POST https://domain.eu.auth0.com/passwordless/start with body: { “client_id”: “client_id”, “connection”: “email”, “email”: “email”, “send”: “code”, “authParams”: { “scope”: “openid profile offline_access” } } Considering you have setup the passwordless connection you will receive an email. …

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://*****.eu.auth0.com/oauth/token
With password-realm and connection = sms.

Some help would be appreciated…

[jonas.lauber]

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:

Passwordless /oauth/ro replacement?

Thanks for that, @sgmeyer! The mfa flow looks good but I’m not sure it fits what I need and I don’t think universal login will work either. My app allows sign up by email (passwordless only) and once authenticated, users have the ability to add a mobile number which can be subsequently used to login with - I don’t allow sms sign ups. For that I need to be able to send and verify a one time code sent via SMS after which the secondary user (with SMS connection type) is linked to the primary accou…

/oauth2/token endpoint and passwordless login

I am trying to create a passwordless login (sms and email) in a react-native app without redirection to the hosted page. The /password/start endpoint works fine for both sms and email and send a code. The verify code the /oauth/ro has been deprecated in favor of //oauth/token. Using the “Resource Owner Password” Grant type on /oauth/token I the following issue: If I specify a grant type of http://auth0.com/oauth/grant-type/password-realmwith the username and password set correctly and then sp…

Login in with sms pin using /oauth/token endpoint possible?

In response to: https://auth0.com/forum/t/user-info-response-incomplete-using-updated-access-toke/5831 Would I also be able to use the /oauth/token endpoint using a password obtained through the passwordless endpoint? I tried to call /passwordless/start and use the sms pin as the “password” for the /oauth/token endpoint using the realm “passwordless” (also tried “sms”), however it gives me: { "error": "access_denied", "error_description": "Unauthorized" } Isn’t that a valid flow?

[nicolas_sabena]

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.

[n.bijl]

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?

[nicolas_sabena]

@n.bijl

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.

[walco.vanloon]

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?

Thanks!

Regards
Walco