为了从 Facebook 获取 access_token,您必须传输您的app_id
、code
您在授权请求后收到的 以及您的应用程序的secret_key
.
为什么我要传输我的密钥?这似乎很不安全。这是 OAuth 2.0 规范的要求吗?
作为一个相关问题,为什么我需要app_id
在我的请求已经与我的签名时传输consumer_key
?
我有一个工作应用程序,我只是不明白这些要求。
为了从 Facebook 获取 access_token,您必须传输您的app_id
、code
您在授权请求后收到的 以及您的应用程序的secret_key
.
为什么我要传输我的密钥?这似乎很不安全。这是 OAuth 2.0 规范的要求吗?
作为一个相关问题,为什么我需要app_id
在我的请求已经与我的签名时传输consumer_key
?
我有一个工作应用程序,我只是不明白这些要求。
这是OAuth 2.0 规范第 4.1.3 节的要求。
如果客户端类型是机密的或已获得客户端凭据(或分配了其他身份验证要求),则客户端必须向授权服务器进行身份验证,如第 3.2.1 节所述
第 3.2.1 节参考第 2.3节。具体来说,第 2.3.1 节说:
或者,授权服务器可以允许使用以下参数在请求正文中包含客户端凭据:
client_id
REQUIRED. The client identifier issued to the client during
the registration process described by Section 2.2.
client_secret
REQUIRED. The client secret. The client MAY omit the
parameter if the client secret is an empty string.
OAuth 2.0 确实提供了其他方法,但通过选择这种方法,Facebook 完全符合规范。现在为什么Facebook 会选择这种方法,可能只有 Facebook 可以回答。
除了作为 Oauth2 的要求之外,还需要在此步骤中使用 client_secret 来验证您确实是您声称的人。
这一切都归结为为什么这个过程是这样的......
从安全的角度来看,您从第一个请求返回的“代码”本身就很弱。它可能会在返回给您的重定向链接中被劫持,我经常看到该链接在没有 SSL 保护的情况下进入登录页面。即使您在整个网站上都使用 100% HTTPS,但一切都不是完全安全的。有人可以通过查看记录在您的 Web 服务器访问日志中的请求 URL 找到代码。
即使您在白金汉宫这一侧拥有最严格的安全环境来控制对您服务器的访问,如果您已经参加了几年以上的技术竞赛,您知道有人会在某个时候将您的日志“归档”到更少的地方- 非常安全。可能在他们留在星巴克的 USB 钥匙上……
如果您使用服务器端 API 流,没有什么可以避免这种情况。与在客户端浏览器中运行的 Javascript 不同,您不能在哈希之后添加临时代码以防止其被记录,因为浏览器客户端不会在请求中发送任何超过哈希标记的内容。JS可以拦截重定向Url,并解析出Hash标签后面的东西,这就是为什么JS Oauth2流程只返回access_token而无需额外的中间代码歌舞。JS 端也不需要 Client_Secret,这很好,因为当您将密码和密钥放在 javascript 中时,它通常会令人不悦。
现在,为了防止这个中间代码被坏人用来获取访问令牌,Client_ID 和 Client_Secret 会被发送,以便 API 服务器可以验证您是您声称的身份,并且您有权兑换access_token 的代码。没有什么比共享的秘密更重要了!
由于代码在过期之前的使用窗口非常短——基本上是为了让你立即将其兑换为 access_token——所以有人窃取代码并试图暴力破解 Client_Secret 的危险不太可能。
使用短窗口和 client_secret(当然通过 ssl)的组合提供了一个您稍后与您的客户端凭据交换的
注意这些词......不推荐。
2.3.1。客户密码
拥有客户端密码的客户端可以使用 [RFC2617] 中定义的 HTTP 基本身份验证方案与授权服务器进行身份验证。客户端标识符使用附录 B 中的“application/x-www-form-urlencoded”编码算法进行编码,编码值用作用户名;客户端密码使用相同的算法进行编码并用作密码。授权服务器必须支持 HTTP Basic 身份验证方案,以对已获得客户端密码的客户端进行身份验证。
例如(仅用于显示目的的额外换行符):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
或者,授权服务器可以支持使用以下参数在请求正文中包含客户端凭据:
client_id 需要。在第 2.2 节描述的注册过程中发给客户端的客户端标识符。
client_secret 必需的。客户机密。如果客户端密码为空字符串,客户端可以省略该参数。
不推荐使用这两个参数在请求正文中包含客户端凭据,并且应仅限于无法直接使用 HTTP 基本身份验证方案(或其他基于密码的 HTTP 身份验证方案)的客户端。 参数只能在请求正文中传输,不得包含在请求 URI 中。
例如,使用主体参数刷新访问令牌(第 6 节)的请求(带有额外的换行符仅用于显示目的):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
当使用密码验证发送请求时,授权服务器必须要求使用第 1.6 节中描述的 TLS。
由于此客户端身份验证方法涉及密码,因此授权服务器必须保护使用它的任何端点免受暴力攻击。