我的身份服务器应该拥有用户配置文件吗？

Question

目前，我有一个移动应用程序(M)、一个单一的web (A)和一个标识4服务器(I)。

我的目标是一种微型服务DDD方法。

我的身份服务器应该在自己的数据库中拥有用户配置文件(用于注册/签名)，还是我的API应该在其数据库中拥有它们？

让场景1拥有它们，让场景2拥有它们。

在我看来，情景1是有意义的，但我对这个问题的假设如下：

场景1，注册：

我只有一次身份验证之旅。

M -> I -> M

场景1，签名：

我只有一次身份验证之旅。

M -> I -> M

场景2，注册：

我有一次旅行

M -> A -> M

场景2，签名：

移动应用程序与身份对话，它要求API检查用户，成功后将令牌发送回移动应用程序。

M -> I -> A -> I -> M

或者，移动应用程序与API对话，API成功地从标识中获取令牌，然后将它们发送回移动应用程序。

M -> A -> I -> A -> M

Answer 1

我倾向于让我的身份&访问控制BC拥有用户和相关权限，并且有一些API (rest、assembly)可以显示相关的功能，我遵循您的模式的这个版本：

M -> A -> I -> A -> M

如果我有一个网站(S)，那就是：

S -> A -> I -> A -> S

当我执行登录时，将创建一个新会话，并根据该会话注册用户的权限，因为获取它们可能是一项昂贵的工作。

然后对此缓存版本的权限执行所有授权。如果权限更改，则仍将根据现有会话权限授权用户。如果这是不想要的，那么会话可能在权限更改后过期。

Answer 2

用户将存在于这两个地方，主标识位于标识服务器中，任何相关的应用程序范围都声称存在于api中。

您可以在发出令牌中设置粗略的声明，但这将导致在发出令牌期间，声明是有效的，或者更糟的是，在每次调用时检查标识服务器是否存在已撤销的令牌。

您通常要做的是使用ASP .net，至少是使用claims转换，它可以用于获取所提供的用户id (或声明)并添加到其中--也称为索赔充实。

这样，对用户访问权限所做的任何更改都将在每次调用上运行的转换过程中得到。

由于这种情况发生在本地进程中，因此不需要外部系统，而且速度很快，并且(应该)松散地与任何其他系统耦合，只要求为本地应用程序提供有意义的安全角色。

请原谅C#示例，因为您不确定正在运行哪些代码(可能是.net给定身份服务器吗？)无论哪种方式，本文都提供了在本地应用程序Add claims with Owin Middleware中转换索赔的一般过程。