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

Viewed 309

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.

1 Answers

The Auth0 helps you to handle authentication process and your API needs to determine what users can and cannot access with each request. This process is known as authorization. In other words authentication starts on the client-side, while authorization starts on the server-side.

AUTHENTICATION (client)

In your example, client sends directly the phone number to Auth0, Auth0 (Twillio behind the scene) sends back the code.

Client sends back the credentials(phone number and code) to Auth0 that validates them. Once the code is successful, Auth0 encapsulates access information in something called an access token (JWT- JSON Web Token) and identity information in something called an ID token. More about tokens here https://auth0.com/docs/tokens

The mobile application stores the access token and refresh token locally.

AUTHORIZATION (backend)

When the user needs to make a request to a protected API endpoint, the client application must send the access token with the request for the API to then carry out the authorization process. The access_token must be in the authorization header of every request it makes to protected endpoints.

The server validates the access token. If access_token is not valid, use the refresh token to obtain additional access tokens. If valid, the server determines if the token bearer can access the requested endpoint using information within the token.

You server (point 3 in your question) needs few things to start authorization process. You will have to validate the access token using JWT Strategy. If you are using nodejs, there is a good module called Passport which can help you with that.

To configure JWT Strategy you'll need two values from Auth0: an Auth0 Issuer URL and an AuthO Audience. You will get these values by creating api in Auth0 dashboard.

That means Passport validation is all handled by Auth0 in your created tenant (api) in Auth0 dashboard. Auth0 determined the identity of the logged-in user and then passes data about the user within payload object which you can access throughout the request-response cycle through controllers and middleware.

Your protected endpoints e.g /account automatically invokes your JwtStrategy configuration logic and blocks request if the access_token is not valid.

This article helped me a lot to understand OAuth flow which I quoted here a lot :) https://auth0.com/blog/developing-a-secure-api-with-nestjs-getting-started/

Related