我目前正在尝试将 Multi-Tenancy 系统从“自定义”身份验证和授权实现迁移到 OAuth2。
Multi-Tenancy 模型与 GitHub 的结构非常相似，因此我将使用它作为主要示例。让我们假设在应用程序中我们有用户、存储库和组织。用户可以直接访问存储库，也可以通过他们所属的组织访问存储库。根据他们的访问权限，用户应该对存储库和子资源(如/repository/issues)或组织及其子资源(/organization/members)对管理它们的用户具有不同的权限。与 GitHub 的 OAuth2 解决方案不同，该系统应该能够跨存储库或组织提供不同级别的权限(GitHub 通过自定义实现在不同级别上提供)。
目标是保持逻辑尽可能简单，将所有内容封装在授权服务中，并尽可能搭载 OAuth2。
我的方法是部署一个通用的 OAuth2 服务，并使用动态范围处理权限:
user:read user:write repo:read org:read repo:<repo_id>:issues:read repo:<repo_id>:issues:write org:<org_id>:members:read org:<org_id>:members:write 这为客户端和用户启用细化权限，例如用户能够
read + write在他的一个 repo 中出现问题，但只有 read在另一个。虽然这似乎解决了问题，但主要限制是能够请求范围。由于用户不知道他们有权访问的存储库和组织的 ID，因此在联系授权服务器时，他们无法请求正确的范围列表。
为了克服这个问题，我考虑了两种解决方案:
解决方案 1
repo:read 发行代币和 org:read 更深入地思考，结果证明这是不可行的，因为它不支持像
implicit 这样的资助。为 authorization_code除非授权服务器会处理这种资源的“发现”。解决方案 2
前两个步骤对于第一个解决方案是通用的，而对于第三个步骤，用户只能发布租户范围的 token 。来自 extending the OAuth2 with a parameter识别租户 (
/authorize?...&repo=<repo_id> )，使用授权代码授权的客户端必须为每个租户颁发 token 。在第 1 步发布的 token 必须在授权服务器上保留用户的身份，并在用户在租户之间切换时消除重新身份验证的需要。这种方法的缺点是它增加了客户端集成的复杂性，并且可能会以某种方式违反标准。我正在寻找对此的第二意见，这可能会简化问题并确保解决方案符合标准。
最佳答案
tldr;如何使用自包含的访问 token 来传达用户身份信息并保存在 API 端点定义的访问策略？
您现在面临的问题是由于 OAuth 2.0 scope 不匹配造成的能够。 Scope value in OAuth 2.0被定义为由客户端应用程序使用。
The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter.
但是在您的方法中，您尝试使其由最终用户(人类用户)定义。
一种解决方案是使授权服务器独立于权限细节。这意味着，授权服务器只发布对您的服务/系统有效的 token 。这些 token 可以是独立的，包含用户标识符和可选的组织详细信息(声明)。它可能包含您的服务所需的其他详细信息(由您决定)。理想的格式是使其成为 JWT。
一旦您的客户端(系统的消费者，如 GIT 网站)获得此 token ，它就可以调用系统后端。一旦您的系统支持收到 token ，它就可以验证 token 的完整性、所需声明并使用这些声明来确定为该特定用户授予的资源。您为范围定义的权限级别现在存储在您的服务后端中。
这样做的好处是能够让用户身份驻留在任何地方。例如，您可以使用 Google 或 Auzure AD，只要他们能够为您提供有效的 token ，您就可以支持此类用户使用您的系统。这是理想的，因为权限不存储在其中。 super 用户将有能力定义和维护这些权限。
关于authentication - 使用动态范围在 Multi-Tenancy 应用程序中实现 OAuth 2，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51657958/