IdentityServer is for authenticating existing users, not really creating new users.
In our use-case, we have 3 projects playing a part:
- The identity server
- A protected API
- An identity provider (aspnet core identity) project
Users are created by a call to the API, which creates the appropriate structures in the identity provider.
Our identity server makes calls to the identity provider when validating requests for tokens.
Our API uses identity server to protect the resources, and our identity provider to retrieve information we may need about that user that aren’t contained as claims (permissions, for example).
In this way our identity provider can be shared across projects (one user base with different roles), and the Identity Server is purely for authenticating users. All user management functions belong elsewhere.
EDIT:
@peyman We’re not doing anything particular ground-breaking: just using the aspnet core identity framework (http://odetocode.com/blogs/scott/archive/2013/11/25/asp-net-core-identity.aspx).
The IUserStore and UserManager are the main drivers of this. When a user is created they are assigned a role, which for us is based on which application requested the creation of that user. Our implementation of IUserStore is what will ultimately be called by IdentityServer when verifying identity, and the data provided is used by IdentityServer to build up claims. Our resource API is relatively simply protected using Policies for claim based authorisation (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims)