Using IdentityServer vs creating custom JWT based authentication

Question

Authentication is a bit over the top for me.

My understanding is:

1. Client performs the login
2. API or authentication server responds with a token
3. Client calls API (includes a header which holds the token)
4. API checks if the token is valid and if valid responds with a resource

I checked several options:

IdentityServer4

Has the advantage to easily implement 3rd party authentication like Facebook. You can easily use the ASP.NET Core identities to authorize your API based on roles.

Custom (simple) JWT authentication

Reference: ASP.NET Core Token Authentication Guide

With this approach, you have to make your own identity user and fetch it from a database.

Cookie authentication

The client holds the token in a cookie when sending a request you have to send it too.

---

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

I don't know what should I use and why? Why do many recommend to use IdentityServer4; isn't the simple custom authentication enough?

(I have problems with the IdentityUser properties and the "hidden" database checks)

Answer 1

The problem with authentication is that it may be simple to write a few lines of code that accomplish the end goal of authenticating your users, but it's really complex to do so in a way that you won't regret it later; aka my application got owned.

One of the steps to take to try to prevent that from happening is don't try to reinvent the wheel and stick to using current standards. However, even with standards, you need to implement them accordingly and that is why you probably see recommendations like the one you mentioned. I would actually make the same type of recommendation my self, delegate as much as you can to third-party libraries like IdentityServer4 or cloud services like Auth0. (you should know I work at Auth0, so you can consider me biased; however, for a non-biased recommendation you can check ThoughtWorks Technology Radar).

Also, if you store tokens in cookies, although the storage and transmission of the token happen differently this is still a token based-authentication system; for more on the possible implications of choosing a client-side token storage approach check where to save a JWT in a browser-based application.

In relation to CORS, you did not make that explicit, so I thought it may be worthwhile to mention it. You only need to actually worry about CORS if you deploy your front-end and back-end in separate domains because even if development happens in isolation if they share a domain CORS is one less thing you need to worry about.

Conclusion

For a front-end browser-based application talking with a REST API, the most common approach is to go with token-based authentication that relies on OAuth 2.0 protocol to perform the actual issuance of the tokens. Additionally, you should aim to delegate token issuance to a third-party (IdentityServer4 or other) so that you don't need to implement or maintain that part of the system and only need to consume/validate the generated tokens.