microsoft-graph-api - "The tenant for tenant guid ... does not exist"使用客户端凭据流(守护程序)访问 Microsoft Graph API 时

Question

我想从控制台应用程序定期访问 Microsoft Graph，以便将邮件从 Outlook 邮箱复制到数据库。为了以编程方式进行身份验证，我必须使用 Microsoft Graph 的“客户端凭据流”。

这些是我必须采取的步骤:

1. 在 Azure 门户中注册应用并为其创建客户端密码。

2. 添加我需要的所有权限并授予他们访问权限:

   

3. 让管理员通过首次访问来确认这些权限。这是使用以下 URL 完成的:

   https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
   ?client_id={app id}
   &state=1234
   &redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient
   &scope=https://graph.microsoft.com/.default
   

   我收到以下回复:

   admin_consent: True
   tenant: ca566779-1e7b-48e8-b52b-68**********
   state: 12345
   scope**: scope: https://graph.microsoft.com/User.Read https://graph.microsoft.com/.default
   

   (范围可能会解释此处稍后描述的问题:为什么我配置了 13 种不同的权限时只能获得 User.Read？？)

   

4. 获取访问 token (成功!):

   

5. 尝试读取用户(成功):

   

6. 尝试阅读我自己的电子邮件(没有成功):

   

7. 尝试阅读其他人的电子邮件(用户被邀请以访客身份访问应用程序，但仍然没有成功):

   

我不明白为什么我无法阅读消息，但我可以阅读用户。似乎权限被完全忽略了(我确认我不需要任何权限来读取用户)。

更新

这是我的租户名称:

这些是添加到租户的用户:

重要提示:我的 Azure AD 中没有 Office 365 订阅。所有这些电子邮件都属于不同的广告。

上一个问题"The tenant for tenant guid does not exist" even though user is listed on users endpoint?与我的相似，但我相信这不是重复的，因为我的问题略有不同，并且建议的解决方案使用 OAuth1(我正在使用 OAuth2)。

Answer 1

Microsoft Graph只能访问您已通过身份验证的租户内的数据。这意味着您无法访问来自其他租户的邮箱，即使该用户是您通过身份验证的租户中的 guest 。允许这样做会违反 AAD/O365 租户中数据隔离的基本原则。

还需要注意的是，AAD/O365 和 Outlook.com 是不同的平台。 Microsoft Graph 的核心值(value)支柱是跨 AAD 和 MSA 的通用 API 层，但在幕后，它们正在调用不同的后端。

除了数据隔离和这些不同的平台之外，Outlook.com 根本不支持应用程序权限 (Client Credentials)。您只能使用委派权限访问 Outlook.com，甚至只能使用 limited set of scopes are supported :

Not all permissions are valid for both Microsoft accounts and work or school accounts. You can check the Microsoft Account Supported column for each permission group to determine whether a specific permission is valid for Microsoft accounts, work or school accounts, or both.

关于包含哪些范围，我怀疑这里的问题是您在此租户中没有 O365 的许可证。如果它允许您在没有订阅的情况下同意，这可能(理论上)导致应用程序在/如果稍后添加订阅时意外地获得同意。话虽如此，如果没有看到您要返回的实际 token 的示例，就很难说清楚(请随意发布一个希望我进一步研究的人)。

最后，juunas关于 /me 也是正确的。 /me 段是“当前经过身份验证的用户”的别名。由于您在使用客户端凭据时并未对用户进行身份验证，因此 /me 实际上是 null。