用户在身份服务器和Web API之间同步

huangapple go评论59阅读模式
英文:

User sync between Identity Server and Web API

问题

我的系统看起来是这样的:我有一个带有存储用户的数据库的身份验证服务器,一个带有自己数据库的Web API,以及在Android上运行的UE5客户端应用程序。Web API的任务是保存并返回与用户相关的游戏数据(保存的进度,技能进展等)。我在这方面是新手,想要一切都做得对。我弄不清楚如何在Web API - IS中正确存储和处理用户。

显然,IS必须在其数据库中存储用户以能够对其进行身份验证。但很明显,API必须有一个用户实体以便存储关联的数据。
假设用户注册是IS的责任(我计划在IS端编写注册,尽管我还没弄清楚这是否是最佳实践?),我应该如何同步IS数据库和API数据库中的用户?

假设用户在IS端注册,我应该在回调处理中在API数据库中注册他们吗?

(此外,将来我打算添加Google授权)

我想象了两种糟糕的选择:

  1. 在IS和Web API中使用完全相同的数据库和字面上相同的Users表。- 显然会有很多问题,至少涉及到DBContext状态和迁移。

  2. 将Web API和IS合并为一个项目。

这个问题似乎应该有一个更清晰的解决方案。问题似乎是绝对典型的,但我找不到一个好的答案。

英文:

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.

答案1

得分: 0

我会根据你的要求提供代码部分的翻译。以下是翻译后的内容:

USER MAPPING

通常的设计模式是将用户数据存储在两个保持分离的数据库中:

  • 授权服务器(AS)存储个人可识别信息(PII),例如姓名、电子邮件。
  • 你的业务数据存储用户的业务属性,例如已购买的产品、订阅级别。

这两个数据源都有一个ID,你需要将它们进行映射。我通常通过在业务数据的用户表中添加主体声明来完成这个映射:

  • 授权服务器发放的主体声明
  • 业务用户ID

当你的API接收到访问令牌时,它可以从主体声明中知道用户在业务方面的身份。你的API也可以从访问令牌中获取个人可识别信息字段。

REGISTRATION

这应该在授权服务器中完成,就像你提出的那样。注册和登录成功后,当调用API时,它将接收到一个之前未见过的新主体,然后可以创建一个新用户。

一个更前沿的选项是在注册过程中让授权服务器调用一个API。不过,并非所有的授权服务器系统都支持这种扩展性。在某些用例中,如果需要将业务数据纳入用户验证,这可能是一个要求。

GOOGLE LOGIN

让授权服务器为你管理此连接。这应该使你能够获取相同的主体声明,无论用户如何进行身份验证。这是帐户链接,通常需要你在授权服务器中实施一些属性匹配或脚本。

OPERATING ON IDENTITY DATA

如果你需要在API中对多个用户进行操作,授权服务器应该提供一个SCIM API,以便你的API通过REST HTTP请求获取身份数据。使用这个API而不是共享一个数据库。

英文:

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.

huangapple
  • 本文由 发表于 2023年2月27日 19:30:15
  • 转载请务必保留本文链接:https://go.coder-hub.com/75579897.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定