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