4.4.1.13。威胁：代码替换（OAuth 登录）
攻击者可能会尝试使用受害者的身份登录应用程序或网站。依赖 OAuth 保护的服务 API 提供的身份数据来登录用户的应用程序很容易受到这种威胁。这种模式可以在所谓的“社交登录”场景中找到。
作为先决条件，资源服务器提供 API 以获取有关用户的个人信息，这些信息可以解释为已获得用户身份。从这个意义上说，客户端将资源服务器 API 视为“身份”API。客户端利用 OAuth 获取身份 API 的访问令牌。然后它查询身份 API 以获取标识符并使用它来查找其内部用户帐户数据（登录）。客户端假设因为它能够获得有关用户的信息，所以用户已经通过了身份验证。
如果客户端使用授权类型“代码”，攻击者需要从目标客户端应用程序使用的同一身份提供者收集相应受害者的有效授权代码。攻击者诱使受害者使用与目标应用程序相同的身份提供者登录恶意应用程序（对身份提供者来说可能是合法的）。这导致身份提供者的授权服务器为相应的身份 API 颁发授权代码。然后恶意应用程序将此代码发送给攻击者，攻击者进而触发目标应用程序内的登录过程。攻击者现在操纵授权响应并用他们的代码（绑定到他们的身份）代替受害者的代码。然后客户端将此代码交换为访问令牌，这反过来又被身份 API 接受，因为相对于资源服务器的受众是正确的。但是由于身份API返回的标识符是由访问令牌中的身份确定的（根据受害者的代码颁发），因此攻击者以受害者的身份登录目标应用程序。
影响：攻击者可以访问应用程序和应用程序内的用户特定数据。
对策：
所有客户端都必须在每个请求中指明其客户端 ID，以交换访问令牌的授权代码。授权服务器必须验证是否已将特定授权代码颁发给特定客户端。如果可能，应事先对客户端进行身份验证。
客户端应使用适当的协议，例如 OpenID (cf. [openid]) 或 SAML (cf. [OASIS.sstc-saml-bindings-1.1]) 来实现用户登录。两者都支持对客户端的受众限制。
这让我很困惑：“攻击者需要从目标客户端应用程序使用的同一身份提供者那里收集相应受害者的有效授权代码”。什么是“相应的受害者”以及“身份提供者”在此和后续使用中的含义是什么？
整个攻击描述是模糊的。我开始将其理解为“不应使用 OAuth 2.0 来实现用户登录”，但这是否意味着 Facebook 等主要平台容易受到攻击？并且易受什么影响，究竟是什么？
我可能只需要澄清本段中使用的一些术语。