Processus d'enregistrement des utilisateurs avec IdentityServer4
J'aimerais utiliser IdentityServer4 pour l'authentification dans mon application Web ASP.NET Core MVC, mais le processus d'enregistrement des utilisateurs semble maladroit. La plupart des sites Web qui nécessitent l'enregistrement des utilisateurs ne vous redirigent pas vers un site distinct (par exemple Facebook, Twitter, etc.) pour vous inscrire si vous utilisez des comptes d'utilisateurs locaux.
Une solution consiste à héberger IdentityServer4 dans le même processus que mon client MVC, mais cela est déconseillé.
Existe-t-il de bons exemples concrets d'enregistrement d'utilisateurs locaux avec IdentityServer4?
IdentityServer sert à authentifier les utilisateurs existants, pas vraiment à créer de nouveaux utilisateurs. Dans notre cas d'utilisation, nous avons 3 projets jouant un rôle:
- Le serveur d'identité
- Une API protégée
- Un projet de fournisseur d'identité (aspnet core identity)
Les utilisateurs sont créés par un appel à l'API, qui crée les structures appropriées dans le fournisseur d'identité. Notre serveur d'identité appelle le fournisseur d'identité lors de la validation des demandes de jetons. Notre API utilise un serveur d'identité pour protéger les ressources et notre fournisseur d'identité pour récupérer les informations dont nous pouvons avoir besoin sur cet utilisateur qui ne sont pas contenues dans des revendications (autorisations, par exemple).
De cette façon, notre fournisseur d'identité peut être partagé entre plusieurs projets (une base d'utilisateurs avec des rôles différents), et le serveur d'identité est uniquement destiné à l'authentification des utilisateurs. Toutes les fonctions de gestion des utilisateurs appartiennent ailleurs.
EDIT: @peyman Nous ne faisons rien de révolutionnaire: nous utilisons simplement le framework d'identité de base aspnet ( http://odetocode.com/blogs/scott/archive/2013/11/25/asp-net -core-identity.aspx ).
IUserStore et UserManager en sont les principaux moteurs. Lorsqu'un utilisateur est créé, un rôle lui est attribué, qui pour nous est basé sur l'application qui a demandé la création de cet utilisateur. Notre implémentation de IUserStore est ce qui sera finalement appelé par IdentityServer lors de la vérification de l'identité, et les données fournies sont utilisées par IdentityServer pour construire des revendications. Notre API de ressources est relativement simplement protégée à l'aide de Policies pour l'autorisation basée sur les revendications ( https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/claims )