ASP.NET Core Web API how to temporary save verified phone number

465 views Asked by At

I have an asp.net core web api application with asp.net core identify. In my registration page I have to verify user phone number. In order to do this, I am using twilio which is great. My registration page is built as a wizard. In the second step the user verifies his phone and only in the end of the wizard, a request is made to create the user. My problem is that the twilio code verification can not be used twice. So if I am using it in the second step I can't use it again for the real create request. I need a way to assign this phone number to the user before the registration request occuers. Session could have been great if it was not a web api . I thought about creating a security token with the user verified phone number . This token will be attached to the create request and will have an expiration date. When the user will verified his phone in the second phase the server will return a token with phone and expiration to the client . This will be send along with the user data in the create request. I am not sure this is the right way to do it, and if it is I will really appreciate some help about how to create this token (all the examples I found was creating token for existing user )

1

There are 1 answers

1
Chris Pratt On

Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.

In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.