我正在通过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，这将是该租户独有的？
简短的回答是否定的。当管理员同意你的多租户应用时：
- 在其租户中为其创建服务主体
- 应用请求的权限在该租户中授予
这意味着你的应用现在也可以使用其客户端凭据(id + 机密(对其租户进行身份验证。因此，相同的密钥适用于所有批准的租户。
这意味着你的应用可以在任何给定时间免费获取其中任何一个的访问令牌，无论谁登录。因此，它使应用承担了一些责任，以保持数据分离。
如果从 https://login.microsoftonline.com/company.com/oauth2/token 获取访问令牌，则生成的令牌将包含该租户的标识符。Microsoft图形 API 等 API 只会为你提供具有该令牌的租户的数据。因此，应用必须确保仅使用租户 ID 等于用户的租户 ID 声明的令牌。
我会说juunas的答案是99%正确。 简短的回答基本上是否定的，他提到的考虑也是扎实的。
但我认为，在某些考虑下，这在技术上是可行的。 当管理员同意守护程序服务时，将在客户的租户中创建服务主体。服务主体允许添加可基于每个租户用作客户端机密的凭据。问题是，实际上没有一种方法可以从应用以编程方式将凭据添加到服务主体。必须让管理员运行一些脚本，将新凭据添加到其租户的服务主体。
即使经历了所有这些，也需要确保服务也在客户/租户的基础上隔离。 在安全方面，如果您的单一守护程序有权访问所有机密，则创建每租户客户端机密毫无意义。