We're currently developing a SaaS platform (with a React frontend and an ASP.NET Restful API backend) using the DDD principles. We also use our own Identity Provider (using IdentityServer4).

All IdP-related data is stored in its own seperate database (users, claims, resources,...).

Now there's this issue where we can't wrap our heads around:

Whenever a users logs onto our SaaS platform using our IdP, we want to store some of the user data (id, language, email & name) in our application database. This is because we want to ensure referential integrity between users and other domain entities.

Another reason to store this, is because we need to access users' languages from our domain (to send out emails etc).

So what we can do is read the users' claims and store these in our database. But next to that, whenever a users changes any of this data (lets say a users updates his language) in the IdP, we'd also need to update this data in our application database (since we want the users to receive emails in their set language).

I was thinking of creating a middleware that checks all UserClaims whenever a user performs an API call, but that would mean that we'd constantly have to make a db-request on every API call.

What is the best way to sync user data between the IdP and another database without having to do it manually?

CodePudding user response：

Your application can query the IdentityServer UserInfo endpoint, perhaps every time he logs in (or changes his user profile?) and store the information in the local database.

The question is also how much "eventual consistency" you can accept between your application and your IDP?

One option is to enable this feature and when you change your user profile, you use your refresh token to get a new access token.

UpdateAccessTokenClaimsOnRefresh
Gets or sets a value indicating whether the access token 
(and its claims) should be updated on a refresh token request.

You can read about it here: