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,然后您第一次获得令牌.

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

我想我误解了关于OAuth如何工作的基本信息,但是https://graph.facebook.com/oauth/access_token如果你第一次使用对话框获得令牌,你似乎完全避免了请求.

Answer 1

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

您作为用户想要尝试一个名为Highjack的新Facebook应用程序.所以你点击应用程序和Highjack应用程序.要求您登录您的Facebook帐户.完成后,Facebook会为您生成身份验证代码.

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

在上面的示例中,身份验证代码确认您是用户是有效的FB用户.但第二步说"作为FB用户,您可以访问某些资源的Highjack应用程序".

如果Highjack应用程序需要隐式授权(即直接访问令牌),那么访问令牌也将对您可见,因为它与浏览器交换.这意味着您现在可以使用访问令牌代表Highjack调用所有Facebook API.(您只能使用访问令牌来获取您的个人信息,但Facebook无法知道谁在调用他们的API.)

由于我们有2个派对(You和Highjack)通过Facebook进行身份验证,因此我们有这种双重机制.

Answer 2

从Salesforce文档中无耻地借用:

授权码

授权代码是表示用户访问授权的短期令牌,由授权服务器创建并通过浏览器传递给客户端应用程序.客户端应用程序将授权代码发送到授权服务器以获得访问令牌,并且可选地,获取刷新令牌.

访问令牌 客户端使用访问令牌代表最终用户进行身份验证请求.它的使用寿命比授权代码长,通常为几分钟或几小时.当访问令牌到期时,尝试使用它将失败,并且必须通过刷新令牌获取新的访问令牌.

Answer 3

来自OAuth 2.0规范:

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

所以,基本上 - 主要原因是限制获得访问令牌的actor的数量.

"令牌"响应主要用于生活在浏览器中的客户端(例如:JavaScript客户端).

Answer 4

如果您查看授权码OAuth类型的流程,是的,有精算师的两个步骤:

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

在第1步中:用户告诉OAuth服务器"我想授权此cliet(client_id)访问我的资源.这是我的身份验证(user_session_id或其他什么)"

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

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

如果你真的想要结合step1和step2,你可以这样做:

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

我们在Open Api Platform中使用这种方法,但我们还没有发现任何安全问题.

顺便说一句,实际上存在一个Implicit Grant类型,即:

<client_id, redirect_uri> => access_token, refresh_token

它通常适用于没有服务器后端的仅客户端应用程序.在这种情况下,OAuth服务器必须确保重定向URI属于该客户端(例如,与寄存器redirect_uri相同)

Answer 5

答案）您需要/想要代码和令牌以提高安全性。

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

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

有关更多信息，请观看此精彩视频：

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

Answer 6

理论上，

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

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

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

Answer 7

之所以出现混乱，是因为用户代表自己而不是客户端应用程序通过授权服务器（即，facebook）进行身份验证。保护客户端应用程序（使用https）和用户代理（浏览器）非常简单。

这是IETF-oauth（http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4）的原始公式：

3.4。授权码

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

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

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

Answer 8

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