3

Since IdentityServer's object is to provide authentication and authorization via implementing OIDC and OAuth2 it makes sense to me that user management (CRUD operations) is done separately, maybe in it's own assembly (these seem like two different concerns).

In a production scenario how do you go about separating these two concerns? I see two general options here:

  • There is a separate identity proverider (ASP.NET Identity Core) project/solution that exposes an API to create, update and delete user entities within its storage. IdentityServer calls this API when authenticating a user.
  • The user CRUD action endpoints reside within IdentityServer's host project. IdentityServer has direct access to the DbContext of the identity provider's database and implements all necessary user management operations.

The second approach is obviously the easier to implement, but I think that could mean uneccesary redeployments of the auth server if there are functionality changes regarding to the CRUD user operations.

Also what about functionality like forgotten password, email validation and so on. Where is the proper place for it? With IdentityServer or with the separate IdentityProvider (and IdentityServer calling its API).

I've seen a couple of StackOverflow questions in regard to this, but nowhere could I find a sound sample or good reasoning, everything was vaguely described.

P.S The IdentityProvider will be ASP.NET Identity Core

MultiValidation
  • 823
  • 7
  • 21
  • I would recommend following the official guidelines to start with. – Neil Aug 28 '20 at 14:52
  • Been looking through various docs, samples and articles (official and not) and the best I've read is that IdentityServer should be separate from the user CRUD operations API, but they should both share the same database, which is absurd. A monolith with extra steps. – MultiValidation Aug 28 '20 at 22:45

0 Answers0