Facebook OAuth 2.0“代码”和“令牌”

Question

为什么在 Facebook OAuth2 身份验证流程中需要“代码”和“令牌”，如下所述：https://developers.facebook.com/docs/authentication/？

如果您查看 OAuth 对话框参考 (https://developers.facebook.com/docs/reference/dialogs/oauth/)，您似乎只使用令牌来获取有关用户的信息，并且如果您将 response_type 参数指定为 token 或 code,token ，那么你就第一时间拿到了token。

为什么需要获取“代码”，然后使用代码获取“令牌”而不是直接获取令牌？

我想我误解了有关 OAuth 工作原理的一些基本知识，但如果您第一次通过对话框获得令牌，您似乎完全避免了对 https://graph.facebook.com/oauth/access_token 的请求。

Answer 1

如果你看flow of Authorization Code OAuth type，是的，精算有两个步骤：

1. <user_session_id, client_id> => authorization_code
2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token

在第 1 步中：用户告诉 OAuth 服务器“我想验证此客户端 (client_id) 以访问我的资源。这是我的身份验证 (user_session_id 或其他)”

在第 2 步：客户端 (client_id) 告诉 OAuth 服务器“我已获得用户授权 (authorization_code)，请给我一个访问令牌以供以后访问。这是我的身份验证 (@ 987654329@ & client_secret)"

您会看到，如果我们省略第 2 步，则无法保证客户端身份验证。任何客户端都可以使用不同的client_id 调用 step1 并获取该client_id 的访问令牌，而不是自己的。这就是我们需要 step2 的原因。

如果你真的想把 step1 和 step2 结合起来，你可以这样做：

<client_id, redirect_uri, client_secret> => access_token, refresh_token

我们在我们的开放 API 平台中使用了这种方法，我们还没有发现任何安全问题。

BTW，其实还有一个Implicit Grant type，就是：

<client_id, redirect_uri> => access_token, refresh_token

它通常适用于没有服务器后端的仅客户端应用程序。在这种情况下，OAuth 服务器必须确保重定向 URI 属于该客户端（例如，与注册 redirect_uri 相同）。

Answer 2

让我们举一个简单的例子来区分身份验证码和访问令牌。

作为用户，您想尝试一款名为 Highjack 的新 Facebook 应用。 因此，您单击该应用程序，Highjack 应用程序会要求您登录您的 Facebook 帐户。完成后，Facebook 会为您生成一个验证码。

然后此代码被传递到使用自己的 FB 客户端 ID、FB 机密和您的身份验证代码的 Highjack 服务器来获取访问令牌。

在上面的示例中，身份验证代码确认您作为用户是有效的 FB 用户。但是第二步说“您作为 FB 用户正在授予对某些资源的 Highjack 应用程序的访问权限”。

如果 Highjack 应用需要隐式授权（即直接访问令牌），那么您也可以看到访问令牌，因为它正在与浏览器交换。这意味着您现在可以使用访问令牌代表 Highjack 调用所有 Facebook API。 （您只能使用访问令牌来获取您的个人信息，但 Facebook 无法知道是谁在调用他们的 API。）

由于我们有 2 方（您和 Highjack）使用 Facebook 进行身份验证，因此我们有这种 2 折机制。

Answer 3

在带有 facebook 的 OAuth 2.0 中，总体概念如下。

Step 1. 通过 GET 请求获取“授权码”

request URI: https://www.facebook.com/dialog/oauth
Params:
    response_type=code
    client_id={add your "App id" got by registering app}
    redirect_uri={add redirect uri defined at the registration of app}
    scope={add the scope needed in your app}
Headers: None

Step 2. 通过POST请求发送授权码获取“Access Token”

    URI: https://graph.facebook.com/oauth/access_token
    Params:
        grant_type=authorization_code
        client_id=<add your "App id" got by registering app>
        redirect_uri=<add redirect uri defined at the registration of app>
        code=<obtained authorization code from previous step>
    Headers:
        Authorization:Basic encode <App Id:App Secret> with base64 
        Content-Type:application/json

Step 3. 使用上述步骤获取的访问令牌并检索用户资源

Answer 4

理论上，

• 访问令牌无法告诉我们用户是否已通过身份验证，但身份验证代码可以。
• 授权码不应用于获取 API 的访问权限，但应使用访问令牌。

如果您有一个单页应用程序或移动应用程序，没有或只有最少的后端，您的应用程序可能希望直接在前端访问用户的 FB 数据。因此提供了访问令牌。

在另一种情况下，您可能希望用户使用 Facebook、Google 等外部身份验证服务提供商注册/登录您的应用。在这种情况下，您的前端会将身份验证代码发送到可用于在服务器端从 Facebook 获取访问令牌。现在您的服务器可以从服务器访问用户的 FB 数据了。

Answer 5

Answer）您需要/想要代码和令牌以获得额外的安全性。

根据 Nate Barbettini 的说法，我们需要额外的步骤来交换访问令牌的身份验证码，因为身份验证码可以在前端通道中使用（不太安全），而访问令牌可以在后端通道中使用（更安全）。

因此，安全优势在于访问令牌不会暴露给浏览器，因此无法从浏览器中拦截/获取。我们更信任网络服务器，它通过反向渠道进行通信。访问令牌是秘密的，然后可以保留在 Web 服务器上，并且不会暴露给浏览器（即前端通道）。

有关更多信息，请观看这​​段精彩的视频：

OAuth 2.0 和 OpenID Connect（简单英语） https://youtu.be/996OiexHze0?t=26m30s（开始 26 分钟）

Answer 6

这是因为访问令牌是使用只有 FB 和客户端知道的共享密钥提供给 AUTHENTICATED 客户端（第三方应用程序）的。用户可以直接请求访问令牌的唯一方法是知道共享秘密，这将使秘密公开并可能导致中间人攻击。此外，虽然 FB 可以保证与用户的安全连接，但 FB 不能保证将令牌传递给客户端是安全的。但是，FB（和 OAuth2）确实需要客户端和 FB 之间的安全连接。访问令牌与客户端公共 ID（通常经过哈希处理）相关联，这意味着只有原始客户端应用程序才能使用它来请求令牌，因为密钥与授权代码一起发送以获取访问令牌。

Answer 7

混淆是因为用户代表他自己而不是客户端应用程序对授权服务器进行身份验证（即 facebook）。 保护客户端应用程序（使用 https）然后保护用户代理（浏览器）非常简单。

这是来自 IETF-oauth (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4) 的原始表述：

3.4。授权码

一个授权码代表一个中间结果 成功的最终用户授权过程并由客户端使用 获取访问和刷新令牌。授权码发送到 客户端的重定向 URI 而不是令牌有两个目的。

1. 基于浏览器的流将协议参数暴露给潜在的 攻击者通过 URI 查询参数（HTTP 引荐来源网址）、浏览器 缓存或日志文件条目，并且可以重播。为了 减少这种威胁，通过短暂的授权码 而不是令牌并通过更安全的方式交换令牌 客户端和授权服务器之间的直接连接。

2. 在直接过程中对客户端进行身份验证要简单得多 客户端和授权服务器之间的请求比 间接授权请求的上下文。后者将 需要数字签名。

Answer 8

基本上，作为Lix's answer 的扩展，访问代码路由允许资源所有者（即 Facebook 用户）撤销对其用户代理（即他们的浏览器）的授权，例如通过注销，而不撤销对离线客户端（即您的应用程序）的授权。 如果这不重要，则无需使用访问代码路由。

此外，提供访问代码是为了确保提供给服务器的令牌实际注册到资源所有者（即 Facebook 用户），而不是用户代理（或中间人）。

这似乎类似于选择隐式与授权代码授予流程的问题。 In fact, here is what looks like an opposite view point?!.

另外，作为Drew mentioned，

访问令牌过期后，尝试使用会失败，必须通过刷新令牌获取新的访问令牌。

另一部分是刷新令牌，但我认为在 FB Docs 中解释得不是很好。如果我是正确的，隐式授权（直接令牌）应该是非常短暂的，但这是要强制执行的，FB.js 似乎隐藏了很多（这个我没有深入研究） .

如果我是正确的，code%20token 是一种优化，允许用户代理拥有令牌并允许服务器在单个请求中启动令牌交换过程（因为网络 IO 上的任何东西都被认为是昂贵的，尤其是对用户代理）。

Answer 9

无耻借用Salesforce Documentation：

授权码

授权代码是一个短暂的令牌，代表用户的访问权限，由授权服务器创建并通过浏览器传递给客户端应用程序。客户端应用程序将授权代码发送到授权服务器以获取访问令牌和可选的刷新令牌。

访问令牌 客户端使用访问令牌代表最终用户发出经过身份验证的请求。它比授权代码具有更长的生命周期，通常为几分钟或几小时。当访问令牌过期时，尝试使用它会失败，必须通过刷新令牌获取新的访问令牌。

Answer 10

来自OAuth 2.0 Spec：

授权码提供了一些重要的安全优势 例如对客户端进行身份验证的能力，以及传输 将访问令牌直接传递给客户端，而不通过它 资源所有者的用户代理，可能将其暴露给其他人， 包括资源所有者。

所以，基本上 - 主要原因是限制获得访问令牌的参与者的数量。

“token”响应主要用于浏览器中的客户端（例如：JavaScript 客户端）。

Answer 11

当用户登录时，您会收到一个令牌。但您可能希望在执行其他操作时更改该令牌。 EG 作为您的应用/页面发布或以offline_access 的用户身份发布。