3

I'm building an API and a Mobile APP in Xamarin. I don't want to confirm the phone number as I'd have to use Twilio or other SMS providers, instead, I want to confirm an email. At the same time, I don't want to create an email token to be sent to the user with a link to click, as API is not MVC and won't have any views.

Instead, I want a 6 digit code to be emailed to the user and then I will create an endpoint in the API where the user will submit that code via the mobile APP, to confirm the email. For example:

var code = await _userManager.GenerateChangePhoneNumberTokenAsync(newUser, newUser.Email);

This creates the code, notice I am passing users email rather than the phone number. This code is now emailed to the user, and the user enters this in the mobile APP. Then:

var confirmed = await _userManager.VerifyChangePhoneNumberTokenAsync(newUser, code, newUser.Email);

This confirms that the code is correct. The boolean resulting from this I will then use to manually set EmailConfirmed in the DB to true

It works. Is it acceptable though? Is there any reason why I shouldn't be doing this?

Karma
  • 1
  • 1
  • 3
  • 9
Varin
  • 2,354
  • 2
  • 20
  • 37

1 Answers1

2

One reason that pops up is that even though it's just a validation code, semantically the function is for phone codes, so it could have some "gotchas" introduced in the future if you use it for e-mails.

By reading the source you can see that the implementation is currently based upon RFC 6238: Time-Based One-Time Password Algorithm, which is generic enough for the e-mail usage as well.

Thus, you know that by using the same method, it's as secure as the RFC 6238 specification as implemented in ASP.NET Identity Core.

You can't just use the class because the access modifier is internal, but following the same idea, there are OTP Libraries for .NET based on the same principle.

Using one of them would ensure that the implementation is as clean and generic as possible in my opinion, but for the quick and dirty solution with the current version of ASP.NET Identity Core, I'd see no issues with the approach.

henry700
  • 179
  • 3
  • 8