Azure AD - 具有守护程序服务和授权代码授予流的多租户，目标租户可以生成 client_secret 吗？答案

【问题标题】：Azure AD - Multi-Tenant with Daemon Service and Authorization Code Grant flow, can a target tenant generate a client_secret?Azure AD - 具有守护程序服务和授权代码授予流的多租户，目标租户可以生成 client_secret 吗？
【发布时间】：2017-06-29 00:18:39
【问题描述】：

我正在通过 OAuth 2.0 协议使用 Azure AD，并且还创建了一个服务/ Dameon 应用程序来处理Microsoft Graph SDK 的身份验证过程。对于服务/守护进程，我创建了一个HttpWebRequest 并传递client_id 和client_secret 以生成一个access_token，然后我可以提供给Microsoft Graph SDK。

我还成功地为目标租户创建了一个对应的服务主体，其中管理员已使用授权码授予流向应用程序授予权限。然后，该应用程序将显示在 (portal.azure.com) 内的 Overview -> Quick tasks -> Find an enterprise app 中。

我的问题是有一种方法可以利用服务/守护程序方法，同时还允许目标租户的管理员授权应用程序，这将允许目标租户创建一个 client_secret 来传递，这将是唯一的那个租户？

【问题讨论】：

标签： azure multi-tenant microsoft-graph-api azure-ad-graph-api daemons

【解决方案1】：

简短的回答是否定的。当管理员同意您的多租户应用时：

在其租户中为其创建服务主体
应用请求的权限在该租户中授予

这意味着您的应用现在也可以使用其客户端凭据（ID + 机密）对其租户进行身份验证。因此，相同的密钥适用于所有已批准的租户。

这意味着无论谁登录，您的应用都可以在任何给定时间免费获取其中任何一个的访问令牌。因此，您的应用承担了保持数据分离的责任。

如果您从 https://login.microsoftonline.com/company.com/oauth2/token 获得访问令牌，则生成的令牌将包含该租户的标识符。像 Microsoft Graph API 这样的 API 只会为您提供具有该令牌的该租户的数据。因此，您的应用必须确保仅使用租户 ID 等于用户的租户 ID 声明的令牌。

【讨论】：

如果是这样，那么是什么限制了租户查看其他租户用户？
编辑了我的问题。应用权限使您的应用有责任为目标租户的数据获取令牌。如果您使用委派权限（守护程序不是这种情况），那么就不用担心了，因为您将始终以用户身份进行调用。

【解决方案2】：

我会说 juunas 的答案是 99% 正确的。简短的回答基本上是否定的，而且他提到的考虑因素也很可靠。

但我相信，在某些考虑下，这在技术上是可行的。当管理员同意您的守护程序服务时，将在您客户的租户中创建一个服务主体。服务主体确实允许在每个租户的基础上添加可用作客户端机密的凭据。问题是，实际上并没有一种方法可以通过您的应用程序以编程方式将凭据添加到服务主体。您必须让管理员运行一些脚本才能将新凭据添加到其租户的服务主体。

即使您经历了所有这些，您也需要确保您的服务在客户/租户的基础上也是独立的。安全方面，如果您的单一守护进程可以访问所有机密，那么为每个租户创建客户端机密是毫无意义的。

【讨论】：