IdentityServer 4 confused on how it all works

Question

I been reading and watching alot about Identity Server 4 and I am still a bit confused on it as there seems to be so many moving parts.

I now understand that it is a separate project and it handles authenticating users. What I still don't get is how does a user get registered to it? Who stores the username/password?

I am planning to have this setup

Reactjs front end 
Asp.net Web Api Core 2
Identity Server

So would it work? All the videos I seen so far talk about doing in memory users what is find for testing but they never talk about registering it over.

I seen some videos where they have an existing database and then hook that up with Identity Server 4 and it checks that database. Yet they don't talk about if your starting fresh or even in their scenario when you sign new people up.

Edit

Camilo Terevinto brought up a point of using "ASP.NET Core Identity" and I been looking into it and have some questions.

My understanding of this is right now like this

1. A user comes to my reactjs site and wants to login
2. Gets sent over to Identity Server 4 (IS4) and types in credentials
3. IS4 looks at my database that contains the ASP.NET Core Identity tables and validates the user
4. If all is good then it goes to IS4 tables and adds whatever it needs.
5. Sends back the user and tokens.
6. Now Reactjs can hit my web api and get other data from it.

My problem is what happens if the user is registering.

1. A user comes to my reactjs site and wants to register

2. User see my html/reactjs form and fills it out

3. Information is sent to webapi and stored in the ASP.NET Core Identity tables

4. Now what, do I have to send the user to my IS4 where they now have to log in? That just seems bad.

   Also in this scenario what would stop someone from just spamming my api with registrations, since it is an open end point.

Answer 1

Who stores the username/password?

The beauty of Identity Server is that it doesn't care. You may use a database, a text file or Active Directory. You are responsible to choose whichever is most appropriate for your use case.

IMO, using ASP.NET Core Identity to manage the CRUD of users (which Identity Server already provides bindings and you can see how it's done in their demos) is the easiest way. If you have used ASP.NET Identity before, what you need to add is just

services.AddIdentityServer().AddAspNetIdentity<YourUserClass>();

---

ASP.NET Core Identity is an optional ASP.NET Core membership library from Microsoft that allows you to register and login users using both internal (Windows, Database) methods and external (OAuth/OpenId Connect - Faceboook, Google, Microsoft account, etc) systems. Microsoft provides a lot of information in the Microsoft Docs site, look here for an introduction.
In this case, think of ASP.NET Core Identity as a medium to providing Identity Server information of your users, roles and claims. You create users through Identity but the actual authentication and authorization is done by Identity Server.

---

You could expose REST endpoints for your React application to be able to register (and probably modify?) your users and their roles. For log-in, the ideal way would be to make the React application contact the Identity Server through the implicit flow.

Ask yourself, however, whether Identity Server is needed in your scenario. If the only application being secured by that Identity Server is the React application, it is most likely a waste and you'd be fine using ASP.NET Core Identity on its own.

---

Regarding your edit, the first flow is almost ok, but:

3. If all is good then it goes to IS4 tables and adds whatever it needs.

This step does not happen. If all is good, IS4 generates the token and returns it.

4. Sends back the user and tokens.

IS4, as any OAuth 2.0 or OpenID Connect solution, only returns to the client the generated token. The token itself contains information about the user, though.

Do keep in mind that ASP.NET Core Identity would be hosted in the same application as IS4, and they can easily (if you want) share the same database.

For the second flow, it's pretty easy to log the user in if Identity is in the same application as IS4 (in fact, this is quite common). If they are separated, you'd likely have to make the React application call IS4 as normally.

---

I said that you could use the same database for Identity and IS4 because, to me at least, it makes sense to keep all the security stuff together (which would be applications and users).

Users information is given by Identity in the Users table, their "profile" data can be stored as Claims (again, using Identity to persist them) and their authorization information either as Claims or as Roles. IS4 will map all roles of a user to a single "roles" claim, so it's your choice there.

As you can see, Identity serves as a store for IS4. Identity creates and maintains the data, IS4 consumes it.

---

Regarding the login/register process, it's quite common to have these in the IS4 application so that all clients use the same views and the users get the same UX across applications. It's pretty easy to even provide different views for login/register based on client id if need be.

Always remember that every single application that wants to contact your IS4 needs to be registered in the IS4 database as a Client and it needs to be enabled. If an application uses a ClientId from an URL different than the one stored in the database, the request is denied to enhance security when a ClientId is compromised or is publicly known, as it's the case for JavaScript web clients.