Oauth Microsoft Graph-使用客户端凭据流访问/me或/user/{id}/端点-请求的用户无效

我们正在使用client_凭证流为应用程序访问租户环境。应用程序具有正确的作用域，我们得到一个访问令牌，该令牌用于其他端点，如

/users

，但在执行以下请求时，我们会收到错误消息

GET https://graph.microsoft.com/beta/me/findRooms
{
    "error": {
        "code": "ErrorInvalidUser",
        "message": "The requested user '{userId}@{tenantId}' is invalid.",
        "innerError": {
            "request-id": "b72d26a3-d0ad-42eb-a3d3-35951cb42b3d",
            "date": "2020-01-21T10:21:28"
        }
    }
}

我知道，当我们只是一个应用程序时，没有“我”，但在这种情况下，我们如何访问这些类型的端点？我也必须有一个用户来扮演吗？在我看来，这似乎违背了这样一个守护进程的目的。找不到关于这件事的任何明确文件。在“使用令牌”部分的文档中，它们甚至引用了a/me端点，这种情况下是不正确的

我已尝试使用在访问令牌中可以找到的所有不同类型的id请求

/users/{id}/findRooms

端点，但它们都不起作用。 其他人也有同样的问题，他们还没有解决

致以最良好的祝愿，

---

Christopher

使用

/users/{user id}

是唯一可以使用客户端凭据的模式。在您的情况下，这应该会起作用，因此可能是您使用的

id

存在问题

为了确保我没有向您提供错误信息，我只是使用客户端凭据流中的仅应用程序令牌进行了测试。在解析该令牌时，我看到

角色

声明如下：

"roles": [
    "User.Read.All"
]

如果首先执行了一个

GET/users？$select=displayname，id

，并且该用户包含在响应中：

{
    "displayName": "Adele Vance",
    "id": "3103c7b9-cfe6-4cd3-a696-f88909b9a609"
}

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#Collection(microsoft.graph.emailAddress)",
    "value": [
        {
            "name": "Conf Room Adams",
            "address": "Adams@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Baker",
            "address": "Baker@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Crystal",
            "address": "Crystal@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Hood",
            "address": "Hood@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Rainier",
            "address": "Rainier@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Stevens",
            "address": "Stevens@M365x330971.onmicrosoft.com"
        }
    ]
}

这是要在您的

findRooms

呼叫中使用的

id

。我做了

GET/users/3103c7b9-cfe6-4cd3-a696-f88909b9a609/findRooms

，并得到以下响应：

{
    "displayName": "Adele Vance",
    "id": "3103c7b9-cfe6-4cd3-a696-f88909b9a609"
}

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#Collection(microsoft.graph.emailAddress)",
    "value": [
        {
            "name": "Conf Room Adams",
            "address": "Adams@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Baker",
            "address": "Baker@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Crystal",
            "address": "Crystal@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Hood",
            "address": "Hood@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Rainier",
            "address": "Rainier@M365x330971.onmicrosoft.com"
        },
        {
            "name": "Conf Room Stevens",
            "address": "Stevens@M365x330971.onmicrosoft.com"
        }
    ]
}

---

是的，这对我也很有用。我在脑海中的形象是，只能使用应用程序访问令牌。因此，我测试的是我获得的访问令牌中任何看起来像用户ID的ID，这给了我上面的错误。是否有理由不允许应用程序请求这些资源？这是一个访问控制的东西，某些用户只能看到某些房间，或者我可以像你一样查询/users端点并获取我找到的第一个用户ID，然后用它来查询/findRooms端点吗？我用一个仅应用程序的令牌完成了这一切。仅应用程序令牌中没有用户ID，因此您应该从GET/users获取ID。仅应用程序令牌中的任何ID都可能是应用程序服务主体的对象ID，这将不起作用。只有两个用户ID-

ID

（GUID）和

userPrincipalName

（和电子邮件地址）。是的-这是显而易见的。我想问的是，为什么应用程序ID（令牌中的appid或sub）或我无法访问这些资源？在图中，所有内容都来自用户，只有少数例外，因此URL中必须有一个有效的用户

/me

不起作用，因为如果用户未登录，则没有“me”。应用ID无效，因为它不是用户：）。不幸的是，

/findRooms

API被附加到用户实体。然而，它的替代品，即，并没有连接到用户。对于您的场景，这可能是一个更简单的解决方案，避免了查找用户ID的必要性。谢谢Jason，这个答案非常有用！