implement phone authentication

Question

I am trying to implement phone authentication in my asp.net core backend Apis, something like whatsapp. the flow is:

1. user opens the mobile app
2. if he isnt current user he can write his phone number
3. backend should send verification code to his mobile and store the verificationObject to inMemroyCache with 1 minute expiration time and send verification id to the app.
4. user enters the code then mobile app sends the code with verificationId over https to the backend
5. backend check the code and verificationId stored in the cache.
6. if true backend will send verification Id (not guessable) with status and operation (signin or register new account) to the mobile app with temp token which is stored inMemoryCache with timeout.
7. now mobile app will talk to signin api / register api based on the operation parameter in the previous step. and send the temp access token with no password to the app to authenticate the user

I have separated the Code Verification Api from the rest of the logic based on API best practices as each api responsible of doing one thing.

My question is the other apps follow this practice or there are some other practices? is it right to store temp tokens in the cache rather than store them in the database.

how Firebase handle phone authentication?

Answer 1

If by phone authentication, you mean a One Time Password, my proposed solution would be a user requests OTP and we send them an acknowledgement of their request.

Then, generate a code and save it on some backend database. Next, text the user the same exact code. We are saving the code to a backend database so we can compare it to what the user has sent us.

The user presumably receives the text message, sends us the correct code and it comes to our backend server, we compare the two codes and if the user entered the correct code we will send them some further identifying token, such as a JSON Web Token to identify the user for future requests.

By placing the token on our backend server, it makes it more user friendly and saves us a couple of steps from having to cache anything with a setTimeout or expiration.

So if the user closes the app and doesn't come back to it until a day or two later they can still authenticate and we don't have to worry about a token sitting out there in cache.

I have mostly worked with JSON Web Token and cookies and I am not an ASP.NET developer, to be clear.

One Time Password technology is always an ambitious project to undertake IMO.

So we need to persist the code that the user should be entering into the device so we can compare it at some point in the future. When you generate a code, save it to Firebase so at some point in the future you can reach back out to Firebase and say the user with phone number 212-555-1212 just sent you the code 1234, is that the correct code?

So, the way Firebase works with OTP is you can store the code in Firebase. The challenge though is actually texting the user a code. This is an actual SMS message. To handle that, you can't use Firebase alone, you can integrate the extremely popular Twilio. Twilio is all about interacting with users via phone SMS messages and so we can make use of Twilio to text the user a code.

The other piece is generating a JSON Web Token, again I am not an ASP.NET developer, but it does support JSON Web Tokens from what I glanced at here: JWT authentication for ASP.NET Web API

You can also take care of authentication or user system inside of Firebase. Once the user enters an OTP, we generate the JSON Web Token through Firebase.

So all the JSON storage and all the info that reflects who the user is, all that can be saved on Firebase.

One final thing, I did say we need to compare our code on the server. Well, what server?

Firebase is simply a datastore, it is a place to store JSON data, it does not give us ability to run custom code.

So do you write a server for the comparison of codes? We do NOT want to do this comparison on the user's device.

So what do we do? Also, how do we generate a code? Don't use the user's device for that either.

So where do we generate the code? We know to use Firebase data storage to store the code, but how do we generate it?

Again, I am not an ASP.NET developer, perhaps you can use Node or Express or Python or Rails, but maybe you can find a low-stress low-friction way.

Okay, this is how I see it:

ASP.NET - Show user a form to sign up and sign-in via OTP

Twilio - Send text messages to user

Firebase - Store user data, including user accounts and correct OTP codes

Google Cloud Functions - holy cow, where did this come from?

You can read up on it here: https://medium.com/google-cloud/running-net-on-google-cloud-functions-977e1a1c489

So Google Cloud Functions are code snippets that run one time on demand on Google servers. GCF have tight inter-operability and integration with Firebase data stores.

We can add some logic or processing to the data sitting inside of Firebase. GCF will allow you some custom logic to generate your codes and save them to Firebase and GCF can also compare the code once the user sends it in.

AWS Lambda and GCF are nearly identical in functionality so that could be an option as well. Regardless, what solution you use, they are transferrable skills to have.