How to implement One-Time-Password authentication flow with client, server, database and Auth0

Help
1

I am trying to implement the OTP authentication flow with SMS using Auth0 (Passwordless Connections with SMS using Twillio).

We have a mobile app, an API, a database and we use Auth0.

Steps:

  1. The user enters a phone number.
  • Does the client send directly the phone number to Auth0?
  • Or Does the client send the phone number to the API which calls Auth0 (Twillio)?
  1. The user receives a code through SMS
  • Does the client send the code to Auth0?
  • Or Does the client send the code to the API which then sends it to Auth0?
  1. The user enters the code and receives an access_token, an id_token and a refresh_token
  • Does Auth0 talk directly to the API and the client separately?
  • Should the client receives these tokens and send it to the back end?
  • Or Should the API receives these directly and send back to the client only the id_token?
  1. the user accesses the resource in the database.
  • Does the id_tokem, access_token and refresh_token need to be saved in the database?

These are a few questions I have but I am more confused about the general authentication flow with OTP.

I also asked the question on stackoverflow:

Thanks!

2

In general, the approach would be for the client application to perform direct communication with your Auth0 service domain both to start the flow (send phone number to which OTP will be sent) as well as to complete the flow (exchange OTP code for tokens).

The above is covered in this reference documentation (https://auth0.com/docs/connections/passwordless/guides/embedded-login-native).

The mobile application would then store the access token and refresh token locally; use the access token to call your API while the access token is valid and use the refresh token to obtain additional access tokens.

From the received access token the API would be able (after validation) to trust that the call is associated to a specific user as the access token will contain the user identifier. The ID token should only be processed by the client application and may be used by the client (after validation) as means to populate the user interface with information about the currently logged in user (as in, about the user to which the access token is also associated).

2 Likes
4

Ah thanks, it makes more sense to me now. I am getting a better understanding of the Authentication process (starting in the front end) and the authorization process (starting in API).