azure - 何时将 OBO 与 Azure 结合使用

Question

我想在 Azure 上开发一个 SaaS 应用程序并部署到 Azure 市场。此应用程序将能够获取有关用户网络的信息。（例如 VNET 信息）。理想情况下，我希望有一个单页应用程序，该应用程序将与订阅该应用程序的用户进行身份验证，然后在后端 API 层上进行调用，该层将调用 Azure 管理 API 端点。

Azure 文档布局了应用程序如何与 AD 交互的许多方案。操作指南

我相信我尝试做的最接近于“构建调用 Web API 的 Web 应用程序”流程，这是 OBO 的一个示例。我的问题是，这真的是在描述我在做什么吗？“调用 Web API”真的是在 microsoft azure 平台上调用 API 的示例吗？

所以我的理解是我会开发自己的 API 应用程序，它会接受来自我的客户端浏览器代码的请求，其中包含一个 oauth 令牌，然后 API 层会派生另一个令牌传递到 Azure API 层？

我试图使架构尽可能简单，但恐怕我可能会误解 Azure 文档。

标签： azureazure-active-directory

Answer 1

OBO（代表）允许您将您的 API 收到的访问令牌交换为另一个 API 的访问令牌。重要的是，访问令牌必须是在用户的上下文中获取的，并且必须包含用户信息。新的访问令牌也将包含该用户的信息。

因此，它允许您的后端 API代表当前用户调用 Azure 管理 API。这意味着您的 API 无法执行当前用户无法执行的任何操作。它仅限于用户自己的访问权限。

身份验证的另一个选项是使用客户端凭据身份验证，您的后端 API 仅使用客户端 ID + 证书/密码进行身份验证。在这种情况下，令牌将不包含用户信息。要启用此方法，目标组织的用户必须将 RBAC 访问权限分配给您的应用程序的服务主体，以便它可以自行操作。您还可以在您的应用程序中构建一个流程，您可以在其中代表当前用户设置这些 RBAC 访问。

就个人而言，我更愿意尽可能使用委托访问（OBO），因为它会阻止用户做他们不能做的事情。但另一方面，基于服务主体的访问允许组织更好地控制您的应用程序的访问。