I'd like to use IdentityServer4 for authentication in my ASP.NET Core MVC web application, but the user registration process seems awkward. Most web sites that require user registration don't redirect you do a separate site (e.g. Facebook, Twitter, etc.) to sign up if you're using local user accounts.
One solution is to host IdentityServer4 in the same process as my MVC client, but that is discouraged.
Are there any good real world examples of local user registration with IdentityServer4?
IdentityServer4 support will last until the end of life of . NET Core 3.1 that means till November 2022. In that way, Duende provides new documentation for the fifth service version.
IdentityServer is an authentication server that implements OpenID Connect (OIDC) and OAuth 2.0 standards for ASP.NET Core. It's designed to provide a common way to authenticate requests to all of your applications, whether they're web, native, mobile, or API endpoints.
In addition to the authentication cookie, IdentityServer will issue an additional cookie which defaults to the name “idsrv. session”. This cookie is derived from the main authentication cookie, and it used for the check session endpoint for browser-based JavaScript clients at signout time.
IdentityServer is for authenticating existing users, not really creating new users. In our use-case, we have 3 projects playing a part:
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://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With