我们有一个多实例Saas应用程序：
- 我们的每个客户都有自己的实例和自己的站点子域
- 我们的应用程序(Web应用程序和API)受Azure保护，目前具有ADAL javascript库
- 我们还有第二个API用于需要保护的系统级集成，目前使用第二个"原生"azure应用程序，但这可能不正确，我们希望整合
- 我们的应用程序通过AzureAD Graph API和Microsoft Graph API读取和写入Azure AD(包括密码重置调用)
我们正在研究Azure AD应用程序配置选项，并希望确保我们正在构建最明智、最安全的Azure AD应用。以下是我们一直在查看的一些文档：
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds
https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare
我们希望该应用程序是多租户的，以简化配置，并允许在Gallery中使用；但在考虑这样做时，我们会遇到一些安全问题。
A。使用哪个应用程序版本
- 1)v1。允许同时访问Graph API。正如微软建议的那样，当我们不关心微软账户时，我们应该使用它
- 2) v2。查看MS Graph API文档时，建议使用v2。据说不适用于AzureAD Graph API？允许同一应用程序具有多种类型(Web应用程序/API和本机)，我们可能需要也可能不需要保护我们的Web API和系统API(我们仍在尝试对其进行建模)
B。当我们的客户有不同的子域时，如何管理回复URL
我注意到以下选项：
- 1)在应用程序注册表中，我们为所有客户添加回复URL。这似乎还可以，因为我们只需要做一次，但感觉很奇怪。回复url的数量有限制吗
- 2) 有一个回复url，但管理一个外部工具，利用state url参数将响应路由到正确的实例。微软似乎在这个链接中建议：https://learn.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) 服务主体有没有办法在创建时为其目录生成一个唯一的密钥？这能以编程方式返回给我们的应用程序吗？也许是在管理员同意期间
非常好的问题。我会尽力回答每一个问题，但如果有人有其他想法，请随时评论/添加你自己的答案。
A。使用的应用程序版本
v2应允许您调用Azure AD Graph API。您链接的文档显示了指定Azure AD Graph作用域的示例：
GEThttps://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&scope=https%3A%2F%2Graph.windows.net%2Fdirectory.read%20https%3A+2F2Graph.windows net%2FDdirectory.write
如果您应该使用v2，主要决策点是：您需要支持不在Azure AD中的Microsoft帐户吗如果是，则需要使用v2。否则，使用v1就没有问题(嗯，缺少动态权限)。
由于您正在使用Azure AD Graph修改内容，我猜纯Microsoft帐户将不适用于您我建议继续使用v1。
v2也有一些限制：https://learn.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中指定任何子域。
不过请注意，在撰写本文时，通配符回复URL在v2中不受支持。
C。如何管理对Graph API(AzureAD和Microsoft Graph)的授权
使用多个密钥毫无意义，因为它们都是相等的：)它们中的任何一个都可以用来调用另一个租户。
您可以将机密/证书存储在Azure密钥库中，然后使用Azure AD托管服务标识在应用程序启动时获取它。
我更喜欢使用委派权限，但如果应用程序的用户无权做你的应用程序需要做的事情，那么这是行不通的。
我只想确保客户的实例不可能用另一个租户id调用API。同时也要确保令牌缓存以这样的方式分离，即不可能获得另一个承租人的访问令牌(实例上的内存缓存会很好)。