Microsoft Identity Platform 代表用户与代码流答案

【问题标题】：Microsoft Identity Platfrom on behalf of user vs Code flowMicrosoft Identity Platform 代表用户与代码流
【发布时间】：2022-02-04 20:29:20
【问题描述】：

我正在阅读 Microsoft Identity Platform 的文档以实现 api 并使用 Microsoft Identity 平台对其进行保护，并且我确实了解一些 OAuth 代码授予流程和客户端凭据流程（用于守护程序应用程序）。

现在，当我阅读文档时，它不断提到“代表用户”和“代表自己”的授权。所以我的问题是“代表用户”与代码授予流程相同吗？同样，如果客户端凭据流是“代表自身”。

如果不是，那么“代表用户”与代码授权流程之间有什么区别。真的很想理解，因为它让我感到困惑。谢谢

【问题讨论】：

标签： oauth-2.0 microsoft-identity-platform

【解决方案1】：

Azure AD 支持以下 OAuth 流/授权：

隐式
授权码（带/不带 PKCE）
代表
客户端凭据
设备代码
资源所有者密码凭据
刷新令牌

文档链接：https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols

在大多数情况下，应用程序将获得一个访问令牌，允许它代表已登录的用户执行请求。访问令牌既包含请求令牌的应用程序的信息，也包含登录用户的信息。这允许目标 API 检查应用程序的访问权限（范围也称为委托权限）和用户的访问权限（角色/其他形式的访问控制）。

“代表”流程在这里可能有点令人困惑，但它有一个特定的目的：将使用其他流程之一（客户端凭据除外）获得的访问令牌交换为新的访问令牌。它用于客户端应用程序使用的场景，例如授权代码流调用 API A，然后 API A 想代表同一用户调用 API B。

客户端凭据流是唯一不同的；使用它时，应用程序只提供自己的凭据，不涉及用户。因此访问令牌只包含应用程序信息，应用程序将作为自己执行请求。目标 API 通常只会检查令牌中的角色（应用程序权限、具有允许的成员类型应用程序的应用程序角色），但它也可以检查调用应用程序的 id，如果它在某处存储了允许的应用程序列表。

【讨论】：

感谢您的快速回复。就像您提到的“代表”场景在客户端应用程序使用时很好，例如授权代码流调用 api A，然后 API A 想代表同一用户调用 API B。因此，在我的情况下，我有一个调用受 Microsoft 身份平台保护的自定义 API 的客户端应用程序。此 API 不调用任何其他 API。那么为什么微软文档将其称为“代表”。他们不应该只是将其称为授权授予流程。
你能链接到那个页面吗？
docs.microsoft.com/en-us/azure/active-directory/develop/… - 还要检查此链接并搜索“（终结者）”和最后一个链接。“docs.microsoft.com/en-us/learn/modules/…docs.microsoft.com/en-us/azure/active-directory/develop/…。我添加了 3 个链接，因为我正在寻找回答我发布的问题。
啊，我明白了 :) 可能存在一些混淆，因为客户端凭据以外的流程允许应用“代表”用户执行操作，其中一个流程称为“代表”的”。