我试图在我的REST API中添加一些需要跨用户交互的业务逻辑。我们已将资源服务器和身份验证服务器分开。
在用户之间进行交互的正确方法是什么，例如搜索其他用户的名称，电子邮件++，如果在同一个＆＃34;组内＆＃34;在资源服务器。到目前为止这个问题的原因是因为没有用户信息（或应该？）存储在资源服务器中。仅限OpenID Connect提供程序提供的标识符。
现在通过userinfo端点获取经过身份验证的（我自己的）用户信息当然没有问题。但是，没有什么可以告诉我其他用户（不是我）。同样，我认为通过id＆＃34;得到userinfo是不明智的。 身份验证服务器上的端点。
处理此类问题的最佳方法是什么？是否有一套针对此的最佳实践规则？我是否真的需要将每个用户信息保存两次？进入身份验证服务器后进入资源服务器？如果是这样，那么同步这两个用户模型的正确方法是什么，因为它们除了唯一标识符之外完全解耦。
答案 0 :(得分：1)
有两种情况。
资源服务器和授权服务器都连接到一个包含所有用户信息的数据源。
资源服务器和授权服务器连接到两个不同的数据源，连接到授权服务器的数据源包含用户信息。< / p>
取决于您的应用程序要求，您使用的是哪种情况。但两种情况下跨用户交互的情况都不同。
正如您所提到的，它清楚地表明您的应用程序需要在某种程度上查看其他用户的信息（就像我们在Facebook上看到的那样）。
如果您使用案例1 ：您可以向登录用户公开所有用户信息（当然，您会将用户个人资料公开给登录用户，而不是帐户信息）和登录用户只需要他/她自己的凭据登录和查看其他用户（就像在图书馆管理系统中查看图书一样）
另一方面
如果您使用案例2 ：您可以拥有另一个（例如用户休息API ）其他API，该API将连接到包含您的用户的数据源它会将用户暴露给您的资源服务器。此API将受授权服务器的保护。
然后，您的资源服务器也将通过 client_credential 流程成为授权服务器的客户端。 用户rest API 只会将用户公开给您的资源服务器，资源服务器外的任何人都无法从用户rest API 中获取用户。
您的资源服务器将获取用户rest API 的访问令牌，并使用该访问令牌获取所需的用户信息。您的用户rest API 会将所有用户端点公开给您的资源服务器（例如“/ AllUsers”，“/ SearchUser”等）。
我的推荐：
如果您没有任何特定要求将资源服务器和授权服务器的数据库分开，我建议您使用案例1.这是如何我想这是非常简单明了的方法。
但是，如果您有一些特定要求将资源服务器和授权服务器的数据库分开，那么在案例2中有一个解决方案。