OTP Login with .NET Core for Mobile-Friendly Web Apps

When we build web applications, implementing authentication plays a vital role in providing personalized and secure services. But as we all know, typical authentication mechanisms like usernames and passwords could also become a bottleneck for specific use cases.

Why isn’t user registration suits for all the user cases?

Let’s take the example of placing a doctor’s appointment online. If the application asks for user registration, it will be a hassle for some of the users. Here, the objective of a user is to put the appointment and quit. Besides, using social logins like Google or Facebook will also become a question since this is just a short-term engagement.

Using One Time Password (OTP)

For these kinds of scenarios, we can consider using One Time Passwords (OTPs). For instance, if we take the same example of placing an online doctor appointment, asking for a user’s mobile number and sending an OTP is convenient for new users without asking them to register. Besides, asking for the user’s mobile number is helpful since the application can send the confirmation message to the mobile as an SMS.

OTP Implementation

The following diagram illustrates a typical workflow involved in OTP based login.

OTP workflow

When implementing the OTP login, you can use an identity provider like Identity Server 4 to perform the entire authentication flow. The identity provider will help to plugin OTP login to OpenID connect, or OAuth2 authorization flows, taking care of the heavy lifting after verifying the OTP. However, you need to implement the issuing of the OTP token and validation by extending the Identity Server 4.

Create OTP and Send to the User

To create the OTP Token, you can use the OTP.NET library to both generate and verify the OTP tokens. OTP.NET implements TOTP and HOTP, which commonly used for multi-factor authentication. Under the hood, it uses a shared key to issue and validate OTP tokens. Therefore, you need to store the shared key securely in the backend.

One of the common questions that come up is to use one shared key or create a new shared key per each OTP generated? In short, Yes, each OTP must use different shared secrets.

Let’s take an example of time-based OTP creation using OTP.NET.

using OtpNet;
var totp = new Totp(secretKey);

After creating the OTP, you will need to store the secret key temporary along with the user session and then send the OTP via SMS (or Email) to the user. We need to store this data temporarily until the user enters the OTP received via SMS on the verification web page for validation.

But what is the best place to store the secret key and user session data temporarily? Let’s find out.

Note: I won’t be going into detail on how to send the OTP via SMS. This step is typically straightforward and available in the particular SMS gateway documentation.

Temporary Storing OTP Secret Key

To store the secret key and user session, we can consider several options in ASP.NET Core, as listed below.

1. Session state.
2. Tempdata with Session.
3. Tempdata with Cookies.

Out of these three options, Tempdata with Session state suits best for storing the OTP secret key and user session. The reasons are as follows.

Reference Session and app state in ASP.NET Core

1. The OTP secret key and user session are kept only in the backend (not transferred to the browser in any form). With this configuration, a Cookie is set in the browser, only referencing the session id.
2. Tempdata automatically gets cleared from the session state after it’s read in another request. This behavior works perfectly with the OTP use case since we need the OTP secret key, and the user session kept only until the OTP is validated.
3. Even if a user enters the OTP wrongly by accident, we can explicitly extend the lifetime of the Tempdata for multiple retries using TempData.Keep.

Conclusion

So as you can see, we can’t request user registration for some use cases. If the user engagement is short-term or even mobile, it’s worth using OTP, which will simplify the user registration.

However, the OTP login doesn’t fit all the use cases. For example, for somewhere the users have long-term engagement, asking for user registration is more meaningful.

Therefore, choosing the correct authentication mechanism is important. Thanks for reading, and if you have any questions, please add to the comments given below.

Learn More

Azure Static Web Apps

Authentication for Flutter with AWS Amplify