User sync between Identity Server and Web API

Question

My system looks like this: I have Identity Server with database to store users, Web API with its database and UE5 client application that runs on android. The task of web api is to save and return game data related to the user (saved progress, skillet progression, etc). I am new in this matter and want to do everything right. I can't figure out how to store and handle users correctly in Web API - IS.

Obviously, the IS must store users in its database to be able to authenticate them. But it's also obvious that the API must have a user entity in order to store associated data. Assuming that user registration is IS's responsibility (I plan to write registration on the IS side, though I still haven't figured out if this is best practice?), how should I synchronize users in the IS database and the API database?

Suppose a user registers on the IS side, should I in the callback processing, register them in the API DB?

(in addition, in the future I am going to add Google authorization)

I imagine 2 bad options:

1. Using in IS and web API one and the same database and literally the same Users table. - Obviously there will be a lot of problems, at least with DBContext state and migrations.

2. Combine web API and IS into one project

It seems there should be a cleaner solution to this problem. The problem seems to be absolutely typical, but I could not find a good answer.

Answer 1

I'll answer this in terms of general design patterns to aim for. Identity Server is an Authorization Server (AS) in standard identity terms:

USER MAPPING

The usual pattern is to store user data in two databases that are kept separate:

• AS stores personally identifiable information (PII), eg name, email
• Your business data stores business properties of users, eg products purchased, subscription level

Both data sources have an ID, and you map these together. I have tended to do this by adding the subject claim to a users table in the business data:

• The subject claim issued by the AS
• The business user ID

When your API receives an access token, it then knows who the user is in business terms, from the subject claim. Your API can also receive PII fields in access tokens.

REGISTRATION

This should be done in the AS as you propose. After successful registration and login, when the API is called, it will receive a new subject, which it has not seen before, and can create a new user.

A more cutting edge option is for the AS to call an API during the registration process. Not all AS systems support this extensibility though. In some use cases it can be a requirement, if you need to involve business data in the user verification.

GOOGLE LOGIN

Let the AS manage this connection for you. This should enable you to get the same subject claim regardless of how the user authenticates. This is account linking, and typically requires you to implement some matching on attributes, or scripting, in the AS.

OPERATING ON IDENTITY DATA

If you ever need to operate on multiple users in your API, the AS should supply a SCIM API to enable your own APIs to get the identity data via REST HTTP requests. Use this rather than sharing a database.