Authentication in ASP.NET Core Web API

Now, the time has come to secure our Web API. In our previous article, we discussed about CRUD and Filter on our Employee Management System. Now, we want to secure the API so that only known user can access the API and do some operation. Lets apply authentication to our Web API.

But before applying authentication, We must know what authentication is and the different types of authentication mechanism present. Let's discuss about these first.

What is Authentication?

Authentication is the process of verifying the identity of a user, device or system. It ensures that the entity attempting to access something like a website, app or network is actually who they claim to be.

This envolves checking something user already know like a password, something they have, like a phone or security token or something they are, like a fingerprint or face recognisition. These method help confirm that right person is accessing the Web or Service. 

For e.g. we have seen that in most websites, it asks to login first using UserId and Password. This is the one way of authentication. It verifies, the user that is accessing is known by matching the credentials.

Above is an simple example of Authentication. There are different ways to identify an user. But in this article, we'll only talk about the most used authentication mechanism present in ASP.Net core Web API. 

 It may seem simple, we've to store the userId and password in the DB and when user tries to login, we just verify the userId and it's password matches or not. In most web apps, the same logic is used. But it has some drawbacks. Let's discuss the drawbacks.

• As we're storing the user's information. We've to make sure that it follows the proper security practices to protect the user's sensitive data.
• We've to provide different types of security mechanism.
• We've to maintain a session, so that user doesn't have to login again and again several times to navigate from one page to another.
• In case of large user base, it will slow down the database, when for each time it verifies the userId and password from database. So, we have to implement some kind of authentication management, which can remember user as well.
• Less reusable.

We shouldn't compromise with user's identity and security. Thus, it will be better if we follow some authentication mechanism already discovered and is trusted by everyone.

• Cookie Based Authentication : After user has submitted the login credentials, the web server sends the cookie in success response, which holds the user's login information. The browser stores it and sends it back to the server with each subsequent request. This is done automatically by the browser without writing any code. This allows the server to recognize the user and maintain their authentication status across multiple requests without requiring them to log in every time. If the cookie is valid, the user is granted access to protected resources. If the cookie is missing, invalid, or expired, the server denies access, thus ensuring that only authenticated users can interact with the application. As the user doesn't have to enter the credentials everytime, it is a smoother experience for a user as well. These can also be vulnerable to CSRF or XSS attacks without proper security practices. Cookies are designed to be used within a single website or domain and not suitable for multi domain application. There can scalability issues as well.
• Token Based Authentication: Tokens are also generated on success login response. It looks like a encoded string, which basically holds the login information and helps the system to verify who you are and what you're allowed to do etc. The most commonly used token format is JWT(JSON Web Token). It should be stored on a secure storage i.e. local storage etc. The token should be passed explicitly on the header or body of the http request to access resource. If the token is valid, then only the user is granted to access the protected resources. This also lessens the user ID and password verification for each request. The main advantage of token over cookie is that it is not tied to single app or domain. Tokens are usually signed with Asymmetric Cryptography, which means it cannot be tempered. To issue and validate token, it needs an service (typically called an OIDC server). 
  If your web API are consumed by other apps, or any client UI's, then you should use Token Authentication for secure call. Also, If you want to share login with other apps, then also you should use Token Authentication. 

To summarize, if we've a single website is domain, then Cookie-Authentication is the best choice. If our web API's are consumed by other system or client UI's or want to share sign in with other apps, then Token Authentication is the best choice. But, for this, it required a service to issue and validate tokens. 

Asp.net core provides built in support for Autentication using ASP.NET Identity. However there are different Identity management solutions present for .NET Web Apps, each with different capability and requirements. Asp.Net core Identity is Open source and provides APIs, UIs and database configuration to store and manage user as well as provides permission management. It also has the support for external authentication using google or facebook, multi factor authentication etc. This also support for both Cookie and token based authentication. 

For most of the scenario this is the only provider we need. 

When Should we use ASP.NET Core Identity

ASP.NET Core Identity is best suitable when your Web App has only client UIs. You have the simple authentication needs. You don't need to scale much. And most important your APIs are not exposed to third parties. if this the case you can go with ASP.Net core identity. Here everything including register, login, reset password, mfa are handled by managed asp.net core Identity.

If you want to expose your APIs to third parties or you want to implement SSO (Single-Sign On) on your web Apps, then OIDC (OpenID Connect) server is good fit. You can use self host or manager Identity server based on the requirements. Auth0, Microsoft Entra ID, OpenIdDict are most commonly used OIDC server for Identity management. We'll talk about OpenID connect more on later articles.

For now, we just want to make it clear that when should we use what.

There are some caveats on ASP.Net core identity APIs as well. We can't customize the endpoints such as adding extra user info to the endpoints etc. Also, we can't make the endponts unavailable for users. For e.g. if your application logic don't need self registered users. You can't make it unavailable to the user. Anyone can call the register endpoint to register himself.

Conclusion

So far we've learned what Authentication is and what are the available options for authentication in .net core. In most of the case ASP.Net Core identity provider is enough for your needs. But for enterprise application it's always better to user OIDC provider. 

We've also not talked about Authorization. It always comes after Authentication. So we'll talk about authorization in later articles.