Develop Reference

IdentityServer 4 confused on how it all works

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
A user comes to my reactjs site and wants to login
Gets sent over to Identity Server 4 (IS4) and types in credentials
IS4 looks at my database that contains the ASP.NET Core Identity tables and validates the user
If all is good then it goes to IS4 tables and adds whatever it needs.
Sends back the user and tokens.
Now Reactjs can hit my web api and get other data from it.
My problem is what happens if the user is registering.
A user comes to my reactjs site and wants to register
User see my html/reactjs form and fills it out
Information is sent to webapi and stored in the ASP.NET Core Identity tables
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.

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:
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.
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.

client specific claims identity server4 using asp.net core identity

We need to make a central auth server for multiple applications that we build, while still having roles and claims which are specific to that particular application. Let me explain with an analogy using various services by Microsoft.
I sign up for a Microsoft account and hence my authentication info is stored in a central server. Now i login using the account and assume a fresh start i land up at account.microsoft.com, now i go to msdn click on sign in, it takes me to the login page on auth server then to the consent screen and back to msdn logged in, now i go to xbox and does the same thing. Now MDSN and XBOX are two completely different applications with each having it's own Api, web apps and mobile apps, but using the same auth server.
Till now i have been making independent applications using Identity Framework, and am reasonably comfortable with it, but this is comparatively much more complex than what i have done till now. I was looking through IdentityServer4 to have a central auth server and has completed all the tutorials present on the official doc site, so i have a basic idea of the concepts.
What i need is to have each application be able to specify it's own set of roles and claims without even having any kind of knowledge about other applications, and also the central server will be having external authentications enabled, hence ASP.NET Core Identity in central server.
Current Architecture
Central Identity Server (using IdentityServer4, ASP.NET Core Identity, Entity Framework)
One Central DB for Central Server
Multiple Applications Sets (API, MVC App, Xamarin Mobile Apps)
One or more DB for each application as per need
Things i am able to achieve till now
Customize an identity resource to get user claims stored in db but if i add one roles, it returns me the role repeatedly the number of times as the count of API resources and Clients
Alternate solutions that i came up in my mind
Store the claims and roles in application specific DB, but i guess that i will be facing these issues
too much effort wiring up the auth logic, as it will have to first get the identity from central server and then get claims from the application specific DB
not sure how i can do it using asp.net identity on client side
unused table on central auth server
duplication of auth logic across applications
These stack overflow questions gets the most closest but are not the exact solution
ASP.NET Core Identity and Identity Server 4 - [Roles, Claims and
IdentityResources]
IdentityServer, Claims and Roles
How to add additional claims to be included in the access_token using ASP.Net Identity with IdentityServer4
Any guidance that takes me in the right direction will help
EDIT #1 : It seems like someone has flagged this questions as off-topic, so just want to clarify that i am looking for a specific code/solution using identity server 4 and asp.net core identity and not some recommendation, though any guidance apart from the answer is welcome for better clarifications and understanding, but just the code would suffice, and i feel that it's as per the guidelines of the community.
EDIT #2
I tried doing authorization on client side as suggested by #travis.js but i am unable to understand how do i implement the claims on client side something like [Authorize(Roles="Admin")]

I think your alternative solution is the "right" one.
Addressing your concerns:
too much effort wiring up the auth logic, as it will have to first get
the identity from central server and then get claims from the
application specific DB
Sounds like exactly the right amount of effort to me. The Central Server does authentication and each app does its own authorization.
not sure how i can do it using asp.net identity on client side
You don't really need ASP.NET Identity on the client/app side. Identity is handled by your central server.
unused table on central auth server
Non-issue. But you could still use that table for its intended purpose just at a more macro level.
duplication of auth logic across applications
This does not sound like a duplication of logic. The Central Server does identity/authentication and each app is responsible for determining its own authorization logic.

Securing access to .NET Web API from both MVC client app and mobile applications

I have created a Web API application, an MVC application, and a mobile application.
The Web API should be decoupled from the other two applications as much as possible. I'm using the Password Grant flow here: clients using the Web API needs to send a POST to /Token with username and password. The returned access token is then used for further calls to the API using standard Authorization: Bearer <access_token>.
The MVC application is only accessible for a select few users, and it has its own database which contains the information and roles of these users. Some parts of the MVC application should be restricted to only one or two users (for example), while other parts should be accessible for all registered users. This can be done by using Authorize attributes on the specific controllers within the MVC application - all good. Furthermore, the MVC application should be able to interact with the Web API.
Secondly, I want to have a mobile application to be able to interact with the Web API. A key point here is that I won't require users to register in the app. So essentially, (how it's in my head right now) the only thing the API would see is "this token belongs to the "AndroidApp" user and has password X - sure thing, you're known to me, I'll grant you access". This seems to me a bit 'insecure', meaning that all users of the mobile app will share the same auth credentials.
Questions:
User A is one of the users who are allowed to access the MVC application - I want him to be recognized by both the MVC app, and thereafter the Web API. Is there an easy way to synchronize data between two databases, or should I just register him in both databases (one for MVC, one for API)? There is probably a better third option I haven't thought about.
User B is a user of the mobile application, and he should not be able to access the MVC application. How can this be ensured? Obviously, the MVC user database won't have any info about mobile app users. I'm just wondering about the security aspect of just having one single pair of auth credentials embedded in the app - doesn't sound good to me.
I stumbled upon this question, which basically is the same as mine. But I don't really see the need for Authorization Code Grant flow for the web app (MVC application in my case) as the accepted answer suggests.
I hope my questions make sense, otherwise please let me know :)

My answer doesn't directly answer your question but rather offers an alternative.
In the past when developing similar solutions I've used a specialist third party identity service Auth0.
With Auth0 you can have different application keys, profiles and also create rules (webhooks) which are executed as part of the authentication pipeline. They offer a range of social login as well as AD integration. They offer free and paid pricing.
I am not affiliated with Auth0 in any way, but will use their service as the starting point for any projects going forward - Yes it's a really impressive service!

Abstracting out the OWIN authentication in an MVC web application

I'm working on a solution with others where we have built on a Visual Studio Web Project using MVC (5 I think) and WebApi2.0.
The nature of the solution is that it has 2 DALs, one of the DALs uses SQL to access another applications database, the other DAL uses entityframework codefirst to manage our applications database. There is also a service that is associated with the project so we have done our best to adapt the entire solution into a 3 tier pattern. This means there is a project that contains our BusinessLogic and both our service and our Controllers use it to access the DAL.
So all that out of the way...We are now adding in authentication on the web side. We were stuck for days until we really just embraced Microsoft's default project structure with the OWIN authentication. The downside is that we now have a separate User database that is essentially coupled with the Presentation/Web layer of the solution.
Is there any way to keep all the convenience of the default OWIN authentication in the MVC project AND abstract it out into the LogicLayer? I can't post what we've worked on, but needless to say it's failed every time because we are really struggling to identify what is being done for us behind the scenes (one example is the [assembly: OwinStartupAttribute(typeof(AlarmAggregator.Startup))] annotation). This annotation alone makes me think we will NOT be able to abstract it out.
I know I'm asking to have my cake and eat it too, but I was hoping someone had some insight if it was possible.
At the very least we were hoping there was a way that we could combine our internal database and our user database? I think this would have to happen at the context level? Would it be as simple as pointing our web.config at our internal context?

Since you have not mentioned what those 2 databases are, I assume they are not user databases and out of context. Focusing on the user identity storage, yes its going to be a separate entity unless you are using ADFS, LDAP or something. I would discourage you from building your own identity solution, rather look out for something more widely used and accepted because its a security topic.
Take a look at Thinktecture Identity Server. Its an OpenId Connect based open source solution built in .NET. It comes with its own database, supports same domain SSO, cookie based authentication and supports open id connect. It also supports federated authentication if you want to hookup a ADFS. Its also possible to do social sign in integration with it.
I have integrated .NET, Java and PHP solutions in production to the same instance and everything is fantastic and seamless.
You can host it as a separate service. You can register known clients (your apps and services), their incoming and redirect urls, including post logout Urls, so your application can seamlessly reach out and come back from identity server. The Identity Server comes with all the middleware you would need to protect your APIs and web applications. It also provides REST endpoints for getting and validating access tokens amongst others.
You can also set different scopes to specify the scopes against which a request can be processed.
Much of what I am talking about has directly to do with oAuth 2.0 specs so probably you can read a little about it here if you are not aware of it.
Using a typical oAuth Flow, (e.g implicit flow or authorization code flow), hooking up the right middleware in the Owin pipeline, and decorating your API resources with [Authorize] attribute, your Application will redirect to the identity server page where the user can login. Your APIs(the protected resource) can specify if they are expecting for a specific Scope, when a token is presented and allow to accept/deny your request based on that.
The client registration ensures that only known clients are accepted by identity server(as applications are generally internet facing) and you can either use the MembershipReboot component, also from Thinktecture(also opensource) as your identity store or write your own implementation of a "user service". There are way too many extension points available to play with and you can practically customize everything including the look and feel of the identity server pages to match the UI scheme of your client applications. There is IUserService(to plugin your own user store, ViewLoader to customize UI, CORS policy service to specify allowed origins per client, certificate based TokenSigningService to sign tokens(access/refresh tokens), ScopeStore, ClientStore, TokenHandleStore(to store scopes, client configurations, tokens), ClaimsFilters to filter what claims are included when a token is issued, which is helpful when you use external providers which might return more information that you need to store or provide)
I can go on for ever here but like I said its something available for use and I am using it for multiple applications in production, you can give that a try.
You can have it up and running in 30 mins on your local machine with both Identity Server and MembershipReboot databases setup. The support is very good from the authors and this is a very widely accepted solution for user authentication and authorization.
For example, securing a WebAPI is super simple:
decorate your APIs with [Authorize] and or [ScopeAuthorize] based on your need
This tells the API to go and check if you got something setup for Authorization in the owin pipeline.
In Owin startup just use:
app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions()
{
Authority = "http://your-idserver-url"
});
Yes that is all the change you need in your WebAPI. There is a separate way to setup open id configuration for MVC based web applications but that is anyway available in the documentations with sample code.
The documentation is pretty easy to follow and the server is easy to setup. It takes away all the complexity from your App and services so you can focus on what you want your App to do rather than worrying about handling Authentication and Authorization in each of your Apps or services.

Authenticating in ASP.NET MVC 5 with OWIN and Third-Party system without storing credentials

I want to authenticate a user using a third-party system when they hit a Controller or ApiController with the [Authorize] attribute, but I really don't want to have to create associated users and logins that OWIN requires in order to create the cookie that keeps the user session authorized, because our third-party system is already tracking that.
Normally, you'd map OWIN logins to external logins, but our system, as-is, is so tightly integrated with this third-party system that there are a bunch of reasons (that I won't go into) that we don't want to do that.
Is there a simple way to use ASP.NET MVC5 out of the box that allows you to authenticate to another system, and then mark the session as Authenticated without having to find/register them in OWIN?
Sorry if this isn't a lot to go on. I've not seen any way to go about this without perhaps implementing our own IAuthenticationManager, but I'm not even sure where I'd start to do that.
Thanks for any help you can offer.

I believe OAuth is the only ASP.NET SSO support you get out of the box. It would help if you elaborate on the nature of the third party authentication system, since you'll need to integrate with it in order to provide the SSO experience.
Here are a couple of blog posts explaining how to create custom OWIN authentication middleware, which seems to be what you'll need to do to set ASP.NET Identity based on some information from an external system (header, cookie, token, etc). I used the second approach to integrate with CA SiteMinder (commercial web authentication product).
Owin Auth 1
Owin Auth 2

I ended up solving this by creating my own implementation of IUserStore and its associated classes that wraps the third-party system.