我正在通过OAuth 2.0协议使用Azure AD，还创建了一个Service / Dameon应用程序来处理Microsoft Graph SDK的身份验证过程。对于服务/守护程序，我创建HttpWebRequest并传递client_id和client_secret以生成access_token，然后我可以将其提供给Microsoft Graph SDK。
我还成功为目标租户创建了相应的服务主体，其中管理员使用授权代码授权流程授予了应用程序的权限。然后，应用程序将在Overview -> Quick tasks -> Find an enterprise app中显示在（portal.azure.com）中。
我的问题是我可以利用服务/守护进程的方法，同时允许目标租户的管理员授权应用程序，这将允许目标租户创建client_secret来传递那个租户是独一无二的？
答案 0 :(得分：4)
简短的回答是否定的。当管理员同意您的多租户应用时：
这意味着您的应用现在可以使用其客户凭据（id + secret）对其租户进行身份验证。因此，所有获批准的租户都使用相同的密钥。
这意味着，无论是谁登录，您的应用都可以随时为其中任何一个获取访问令牌。因此，它会对您的应用程序负责，以保持数据分离。
如果您从https://login.microsoftonline.com/company.com/oauth2/token获得访问令牌，则生成的令牌将包含该租户的标识符。像Microsoft Graph API这样的API只会为该租户提供该令牌的数据。因此，您的应用必须确保仅使用租户ID等于用户租户ID声明的令牌。
答案 1 :(得分：0)
我会说juunas的回答是99％正确的。简短的答案基本上是否定的，他提到的考虑因素也很可靠。
但我相信，在某些考虑因素下，这在技术上是可行的。当管理员同意您的守护程序服务时，将在您的客户的租户中创建服务主体。服务主体确实允许添加可以作为每个租户基础上的客户机密的凭证。问题是，实际上并没有办法从您的应用程序以编程方式向服务主体添加凭据。您必须让管理员运行一些脚本才能将新凭据添加到其租户的服务主体。
即使您完成了所有这些操作，也需要确保您的服务也是以客户/租户为基础隔离的。安全方面，如果您的单一守护程序可以访问所有秘密，那么创建每个租户客户机密码毫无意义。