azure - 使用 Azure AD 和应用角色保护 SPA 和 API

Question

我正在构建一个 SPA 可以调用 API 的系统。 SPA 以及 API 在 Azure AD 中使用需要将用户分配给它的应用注册来表示。

在分配期间，用户还会被分配到应用注册公开的角色。 SPA 和 API 应用注册中的可用角色为 Developer 和 User，并且我在这两个注册中为用户分配了相同的角色。

API 注册还公开 SPA 注册用于请求访问 token 的范围。

SPA 中的角色用于呈现不同的 UI 元素，具体取决于用户是被分配为开发人员还是用户。

用户批准 SPA 向 API 请求的范围后，也可以调用 API。此访问 token 的 aud 声明是 API 的应用注册的 ID，它还包含在入门步骤中分配的角色 Developer。

我认为这张图正确地代表了正在发生的事情:

我有几个与此相关的问题，仅通过阅读文档很难弄清楚。

管理调用链中的角色(SPA -> API)

通过系统传播角色的正确方法是什么？所有应用注册是否都需要具有相同的角色，并且用户在每个注册中手动分配角色？

或者我可以传播用户首次登录 SPA 时收到的角色吗？或者这是否会破坏 JWT 的安全性？我猜想这需要在每个应用注册中处理，因为没有什么可以阻止我修改传出请求并将角色设置为 Admin。

角色和范围

我找到了this answer这部分地向我解释了这些概念。我正在构建一个内部系统，除了 OIDC User.Read 提供的(电子邮件、oid 等)之外，并不真正需要任何其他用户数据。 SPA 请求此范围来显示登录的用户名。

除了用户提供的信息之外，我的 API 永远不会需要任何其他信息。在这种情况下我还需要范围吗？
同意仅适用于范围吗？
是knownClientApplications和 preAuthorizedApplications仅在使用范围时适用？

如果这有点漫无目的，我深表歉意，我读了太多文档，以至于无法保持头脑清醒。

Answer 1

我完全忘记了这一点，但问题已经解决了，这里有一些信息，希望可以为其他人澄清一些问题。

如果您的 API 请求用户拥有的数据，请使用范围。如果您的 API 需要处理基于角色的访问，例如用户可以是普通用户、管理员或任何其他用户，您可以使用角色。

我们继续讨论角色，所以这就是我要讨论的内容。我们为 SPA 注册了一款应用程序，为 API 注册了一款应用程序。需要在每个应用程序注册上定义角色，不会传播角色。仅仅因为您是 SPA 的管理员，并不意味着您是支持 SPA 的每个 API 的管理员。

您可以在应用角色边栏选项卡下的应用注册中创建角色。角色本身不会执行任何操作，除非您向它们分配用户或组。用户和组被分配到企业应用程序中与您的应用注册相对应的角色。您可以在企业应用程序的“用户和组”边栏选项卡下进行修改。

• 为每个资源服务器 (API) 定义应用角色
• 应用角色已明确分配给每个资源服务器 (API) 和用户/组
• 与资源(由 aud 声明标识)相关(定义)的应用角色在相应的 token 中颁发
• 用户 A 是 API X 中的管理员这一事实并不意味着该用户自动成为 API Y 中的管理员。否则的话，这是一个糟糕的设计。
• 如果用户 A 是 API Z 中的管理员 Z，这将正确反射(reflect)在通过以下(示例/说明性)链中的代表流获取的 token 中:
  • 客户端 B(例如 SPA)需要通过 PKCE 对用户 A 进行授权 -> 这样客户端 B 即可获取 API X 的访问 token (此 token 中没有角色) -> API X 使用代表流来获取访问 token 对于 API Y(此 token 中没有角色)->(根据设计需要重复此步骤)API Y 使用代表流获取 API Z 的访问 token -> API Z 的访问 token 将具有管理员权限用户 A 的 Z 角色。

在上述代表调用链中，有四 (4) 个应用注册:

1. 客户端 B(SPA 客户端)
2. API X
3. API Y
4. API Z

API Z 不关心(也不应该关心)用户在任何其他系统中拥有什么角色和权限。

角色和声明仅遵循为其定义的资源，并且永远不会包含在其他资源的访问 token 中。

如果您为 SPA 客户端注册的应用定义应用角色，这些角色将仅出现在为 SPA 客户端获取的 id token 中，而不会出现在其他 token 中。

是否应该注册多个 OAuth 资源服务器(应用程序注册)还是仅注册一个并在同一应用程序注册中使用不同的角色和范围，这是有争议的。以 MS Graph 为例 - 实际上只是一个资源服务器，但有数百个(而不是数千个)作用域和应用程序角色。即使如此，用户 A 拥有 Directory.Read.All 权限这一事实并不一定意味着他们应该能够在交换中读取邮件消息。