多实例应用和 Azure 身份验证最佳实践

Question

我们有一个多实例 Saas 应用程序：

• 我们的每个客户都有自己的网站实例和自己的子域。
• 我们的应用程序（Web 应用程序和 API）受 Azure 保护，目前使用 ADAL javascript 库
• 我们还有一个需要保护的用于系统级集成的第二个 API，目前使用第二个“本机”Azure 应用，但这可能不正确，我们希望整合
• 我们的应用程序通过 AzureAD Graph API 和 Microsoft Graph API 读取和写入 Azure AD（包括密码重置调用）

我们正在研究 Azure AD 应用程序配置选项，并希望确保我们正在构建最合理、最安全的 Azure AD 应用程序。以下是我们一直在查看的一些文档：

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds

https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare

我们希望应用程序是多租户的，以简化配置，并允许库中的可用性；但是在考虑这样做时，我们会遇到一些安全问题。

A.使用哪个应用程序版本

• 1) v1。允许访问两个 Graph API。正如微软建议的那样，当我们不关心微软帐户时，我们应该使用它。
• 2) v2。在查看 MS Graph API 文档时，它建议使用 v2。据报道不适用于 AzureAD Graph API？允许同一个应用具有多种类型（Web 应用/API 和本机），我们可能需要也可能不需要保护我们的 Web api 和我们的系统 api（我们仍在尝试建模）。

B.当我们的客户有不同的子域时，如何管理回复 URL？

我注意到以下选项：

• 1) 在应用注册表中，我们为所有客户添加回复网址。这似乎没问题，因为我们只需要这样做一次，但感觉很奇怪。回复网址的数量有限制吗？
• 2) 有一个回复 url，但管理一个外部工具以利用 state url 参数将响应路由到正确的实例。 Microsoft 似乎在此链接中建议：https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/authenticate 我不确定 ADAL 是否允许我们设置返回子域 url 的状态。这种方法常见吗？
• 3) 我们客户端目录中的每个ServiceProvider 实例是否可以将回复url 配置到自己的子域？我觉得这将是最干净的方法，但我没有看到它的文档。如果我们也能以编程方式设置 replyURL 那就太好了。

C.如何管理对 Graph API（AzureAD 和 Microsoft Graph）的授权

我注意到以下选项：

• 1) 使用带有单个应用程序密钥的客户端凭据流（用于所有客户端）。当客户订阅时，他们将管理员同意我们的应用程序授予应用程序对其目录的权限。当然，我们会尽最大努力保护该密钥的安全。但是，如果由于某种原因被入侵，这将使我们所有的客户都面临风险，而不仅仅是一个被入侵的实例。
• 2) 与 1 相同，但使用证书而不是密钥。我知道这可能会更安全一些，但我看不出它不会遇到与 1 相同的问题。
• 3) 不使用应用程序权限，而是对管理员用户使用委派权限。这会很好，因为它本质上可以防止我们的应用程序的一个实例与错误的目录通信。但是更改管理员可能会中断服务；我认为最好的审计方式是让我们的应用程序对其所做的更改负责。 （另外，委托权限是否允许重置密码？我知道您需要运行 powershell 脚本来升级应用程序的目录角色以获得应用程序权限）
• 4) 服务主体是否可以通过某种方式在创建时为其目录生成唯一密钥？这可以通过编程方式交还给我们的应用程序吗？也许在管理员同意期间？

Answer 1

非常好的问题。我会尽我所能回答每个问题，但如果有人有其他想法，请随时评论/添加您自己的答案。

A.使用哪个应用程序版本

v2 应该允许您调用 Azure AD Graph API。您链接的文档显示了指定 Azure AD Graph 范围的示例：

获取https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&scope=https%3A%2F%2Fgraph.windows.net%2Fdirectory.read%20https%3A%2F2Fgraph.windows.net%2Fdirectory.write

是否应该使用 v2 的主要决策点是：是否需要支持不在 Azure AD 中的 Microsoft 帐户？如果是，则需要使用 v2。否则使用 v1 没有问题（嗯，缺少动态权限）。

由于您使用 Azure AD Graph 来修改内容，我猜纯 Microsoft 帐户不适合您。 我建议坚持使用 v1。

v2 也有一些限制：https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations

B.当我们的客户有不同的子域时，如何管理回复 URL？

我找不到有关 URL 限制的文档。您可以添加任意数量的内容。但我不确定:)

如果您的子域如下所示：https://customer.product.com，您可以将回复 URL 配置为：

https://*.product.com

然后它将允许在redirect_uri 中指定任何子域。

请注意，在撰写本文时，v2 不支持通配符回复 URL。

C.如何管理对 Graph API（AzureAD 和 Microsoft Graph）的授权

使用多个键是没有意义的，因为它们都是平等的 :) 它们中的任何一个都可以用来调用另一个租户。

您可以将机密/证书存储在 Azure Key Vault 中，然后使用 Azure AD Managed Service Identity 在应用启动时获取它。

我更喜欢使用委派权限，但如果应用程序的用户无权执行您的应用程序需要执行的操作，那么这是行不通的。

我只是确保客户的实例无法使用另一个租户 ID 调用 API。并且还要确保令牌缓存以无法获取另一个租户的访问令牌的方式分开（实例上的内存缓存会很好）。