What's the added value of using IdentityServer 4 with ASP.NET Core Identity?

Question

TL;DR - Headline :)

Background story: I'm building a set of applications (including RESTful APIs, and several clients - pure web apps, and mobile apps). All the core APIs are going to be written in ASP.NET Core. I want to tackle the authentication-authorization issue.

I don't want to use a cloud or an external service since keeping all the user related data close is in top priority for me (including passwords).

From what I read, it seems like that ASP.NET Core Identity provide all the functionality and processes related to authentication and authorization needed. I can manage a whole user base, including hashed passwords, and all the data-related to a user by myself. It's a collection of abstractions and concretes (which I can extend if needed).

I also read that I can integrate with IdentityServer 4. From what I understand, it grants me an extra layer of security, in a way that I can use it as a security token service (STS) and provides me with the implementation of OAuth 2.0 authorization and OpenID authentication which is great, BUT... is that it? I just want to understand what's my benefit of using it.

My question has 2 parts :

1. What's in between ASP.NET core Identity and IdentityServer 4?
   Does IdentityServer 4 supply some (different) concretes of the abstractions that ASP.NET Identity's provide?
   I want to know the relation between ASP.NET Identity and IdentityServer 4.
2. What's the cost of developing with IdentityServer 4? Is it straight-forward, or it's not the trivial to implement?
   
3. A bonus question :) - Are there any alternatives out there? What would you choose? And why?

the following question has an EXCELLENT answer, which answered a lot of my questions, but I still want an answer specific to my questions.

Thanks in advance!

Answer 1

Well, if it's not obvious by now: You can't create jwt/bearer tokens with ASP.NET Core Identity.

ASP.NET Core Identity uses cookie middleware, which has a few downsides. With the Authorization middlewares available you can consume bearer/jwt tokens, but you can't create your own ones. That's where ASOS & Identity4 close the gap.

Using cookies has several downsides, including the fact that it's generally long lived whereas JWT tokens usually have a short lifetime (5 to 10 minutes) and get refreshed via identity token.

So in case someone obtains a bearer token by eavesdropping the traffic, the token is only valid for a short period and the attacker can't refresh it without the id token.

Second, cookies are more vulnerable to XSS, whereas bearer token are sent per request and are only vulnerable to XSRF, which can be more easily be protected via AntiForgery tokens. See also this answer on security stack exchange.