oauth-2.0 - 在微服务架构中我需要多少应用注册

Question

我有一个微服务架构，其中一个单页应用程序访问三个不同的 API：

我通过 Microsoft 身份平台保护这些 API，因此我还需要服务主体。
我的第一种方法与我在博客或 MS 文档中找到的所有示例相匹配。
在这种情况下，我为客户端应用程序注册了一个应用程序，并为 API 注册了三个额外的应用程序：

这会产生以下影响：

1. 每个 API 都有自己的受众。
2. 我为每个应用程序获得了四个服务主体。
3. 我得到了三个不同的地方，我必须管理用户分配给角色的位置。（例如：用户 A 可以从 API A 等读取资产...）

这可行，但也有一些问题：

1. 其他管理允许哪个用户执行操作的管理员对他们必须分配角色的三个不同位置感到困惑。有一个中心位置会更好。
2. 用户的角色没有放在 ID 令牌中，因为只有客户端应用程序的角色会去那里......但我不想再次在客户端应用程序中分配权限。
3. 如果 API A 想要调用 API B 或 C，我需要两个用于其他 API 的访问令牌。

这让我想到了第二个想法：

在这里，我对所有 3 个 API 进行了一次注册。这已经解决了问题1和问题2。但它也给我一种奇怪的感觉，因为我从来没有发现其他人这样做。
我的 ID 令牌也没有告诉我角色，所以为了解决这个问题，我什至可以更进一步，为所有内容进行单个应用程序注册：

现在，一个注册公开了一个 API，也使用了这个 API。什么是可能的，似乎可以解决我的问题。我什至现在在我的 ID 令牌和访问令牌中获得用户的所有角色。

但是，这与我发现的所有其他示例相矛盾。

1. 最后一种解决方案有哪些缺点？
2. 我应该选择三种方法中的哪一种？

Answer 1

最后一种解决方案有哪些缺点？

我想到的一件事是您希望 API A 能够在例如 MS Graph API 中编辑数据，因此您授予它读取/写入目录数据的应用程序权限。现在，通过共享应用注册，此权限也已授予 API B 和 API C。

所以在第二和第三个选项中可能会违反最小特权原则。但正如您所注意到的，它确实使管理这些 API 变得更加容易。

第三个选项确实为用户打开了获取访问令牌的大门，您可能希望代表当前用户从您的 API 调用任何 API。因此，如果您希望 API A 代表用户通过 MS Graph API 编辑用户，则必须要求读/写用户为您的应用程序委派权限（范围）。这也将允许用户从您的前端获取此令牌，即使这不是故意的。现在他们将无法做他们原本无法做的任何事情，因为令牌的权限受用户权限的限制，因此这可能不是一个明显的缺点。

我应该选择三种方法中的哪一种？

与许多事情一样，这取决于:)

如果您想为您的服务提供绝对最低权限，请选择 1。

如果您想要更轻松的管理，我会选择选项 3 而不是 2。我上面提到的关于选项 3 的一件事，但不允许特权升级。