Using IdentityServer vs. Creating JWT-Based User Authentication

Question

Authentication is a little higher for me.

My understanding:

• Client logs in
• API or authentication server responds with a token
• The client calls the API (includes a header that contains the token)
• The API checks if the token is valid, and if the valid is responding with a resource

I checked a few options:

IdentityServer4

It has the advantage to easily implement third-party authentication such as Facebook. You can easily use ASP.NET kernel identifiers to authorize your role-based API.

Custom (Simple) JWT Authentication

Link: ASP.NET Core Token Validation Guide

With this approach, you must make your own user and extract it from the database.

Cookie authentication

The client holds the cookie token when sending a request, which you must also send.

---

My front-end is written in JS, and the back-end is ASP.NET Core, so CORS.

I do not know what should I use and why? Why do many recommend using IdentityServer4; Is this not a simple basic authentication?

(I have problems with IdentityUser properties and checking for "hidden" databases)

Answer 1

The problem with authentication is that it can be simple to write a few lines of code that achieve the ultimate goal of authenticating your users, but it's really hard to make sure you don't regret it later; otherwise my application has got the property.

One of the steps taken to prevent this is to not try to invent a wheel and adhere to existing standards. However, even with standards, you need to implement them, so you probably see recommendations like the ones you mentioned. I myself would make the same type of recommendations myself, delegate as much as you can into third-party libraries such as IdentityServer4 or cloud services like Auth0 . (you should know that I work in Auth0, so you can consider me biased, however for a non-biased recommendation you can check out ThoughtWorks Technology Radar ).

In addition, if you store tokens in cookies, although the storage and transfer of the token happens differently, it is still an authentication system on tokens; for more information on the possible consequences of choosing an approach to storing tokens on the client side, select where to save the JWT in a browser-based application .

Regarding CORS, you did not make this explicit, so I thought it was worth mentioning it. You only need to worry about CORS if you are deploying your interface and server server in separate domains, because even if development happens in isolation, if they share the CORS domain, this is another thing you need to worry about.

Conclusion

For a browser-based front-end application that uses the REST API, the most common approach is to use token-based authentication, which uses the OAuth 2.0 protocol to actually issue the tokens. In addition, you should strive to delegate the issue of the token to a third-party (IdentityServer4 or another) so that you do not need to implement or maintain this part of the system, and you only need to consume / verify the generated tokens.