I have a flow in my app where a user can link their mobile phone to their account i.e. link an sms connection to an email connection. In short, user enters their mobile number, a code is sent via /passwordless/start endpoint. The user then enters the code and a token is obtained via /oauth/ro endpoint.
The /oauth/ro endpoint is now legacy and I would like to switch to the replacement endpoint before heading to production but there doesn’t appear to be one, unless I’m mistaken. The /oauth/token endpoint doesn’t appear to allow passwordless authentication and responds with a 400 “Passwordless authentication is not allowed on this endpoint”’
The /oauth/ro endpoint was deprecated almost 1 year ago and not available to customers since 8th June 2017 I believe. and I imagine mobile linking is a fairly common requirement for applications. How do non-legacy customers implement this?
I am fortunate enough to be a legacy customer so will revert back to /oauth/ro endpoint but would like to know if support of sms code verification via the auth api is in the pipeline? If not, then I have features of my application that will be lost if legacy support is dropped.
Some sort of roadmap of features would be useful so that we can plan our migration out of legacy.
@craigchapman auth0 always recommends using Univeral Login as the standard way to implement authentication across applications. As of October 2017 the IETF started publishing a best current practice specification for building authentication in mobile/native applications. They call this “AppAuth” for short. If you are interested you can read this here: RFC 8252: OAuth 2.0 for Native Apps
All this means is that instead of using an embedded login for mobil you should use an external user agent (browser flow) in mobile. Most people have seen this in various google applications. Using the universal login page allows MFA, Redirect Rules, and Consent Pages to work with minimal effort.
That aside if you are not willing or unable to do App Auth approach then you can still use an embedded experience. The /oauth/ro endpoint was replaced with /oauth/token where you supply the password grant details. Here is the docs for that:
This endpoint is a bit interesting. If you dont’ set a default directory (db connection) it won’t work for you. Instead you want to use this endpoint with the password realm extension grant. Read the remarks on that endpoint and it will explain the details. Basically password realm grant type allows you to specify a realm (db connection) when calling the endpoint.
As far as MFA goes, this endpoint will return an error mfa_required error along with an mfa_token` if mfa is required. Then you will have to send the user through the MFA flow using this endpoint:
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 account. I had previously implemented this by creating an auth0 user with with phone_verified set to false which triggers an sms to be sent. Following that I could verify the code via /oauth/ro and then link. It’s the 2nd part that’s broken i.e. no way to verify the code that is sent when the sms user is created.
I think a better fit is to switch to twilio/authy for sms verification. This means a slight change to the workflow that delays the creation of the sms user in auth0 until after code verification. This is probably an improvement albeit one I hadn’t planned on implementing.
@craigchapman ah, sorry about that. I had it stuck in my head you were doing MFA. Anyway, the answer above is partially right only by chance. Auth0 no longer supports for new tenants embedded passwordless authentication right now. Legacy customers can still enable this if their tenant was created before June 8th. I do know we plan on moving passwordless to the /oauth/token endpoint and a grant_type, but that is only in planning phase with no commitment to an ETA.
The only way to use passwordless today is via the Universal Login. Customers can use passwordless connections via Universal Login (hosted login page). You can see the notes in our docs here: Application Grant Types
I have switched to Authy Verification api which didn’t require too much effort. Perhaps this feature will be reinstated in Auth0 but safer to switch now and mitigate the risk. I also want to turn off legacy features in Auth0 and move to OIDC conformance and this was preventing me from doing so.
Terribly sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes our bandwidth is just not enough for all the questions that are coming in. Sorry for the inconvenience!
Was there ever further progress on this front? I’m trying to solve the same problem the original user in this thread was trying to solve, and it’s proving rather difficult!
