当前位置：文江博客话题详情

为什么我要传输`client_secret`来获取`access_token`？

发布于 2024-12-04 04:39:55 字数 335 浏览 1 评论 0原文

为了从 Facebook 获取 access_token，您必须传输您的 app_id、授权请求后收到的 code 以及应用的 secret_key 。

为什么我永远传输我的密钥？这看起来显然是不安全的。这是 OAuth 2.0 规范的要求吗？

作为一个相关问题，当我的请求已使用我的 consumer_key 签名时，为什么我需要传输 app_id？

我有一个可以运行的应用程序，但我只是不明白这些要求。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

命硬 2024-12-11 04:39:56

这是 OAuth 2.0 的要求规范，第 4.1.3 节。

如果客户端类型是机密的或已颁发客户端凭据
（或分配其他身份验证要求），客户端必须
与授权服务器进行身份验证，如中所述
第3.2.1节

和第 3.2 节。 1 指的是第 2.3 节。具体来说，第 2.3.1 节说：

或者，授权服务器可以允许包括
请求正文中的客户端凭据使用以下内容
参数：

client_id

<前><代码> 必需。期间向客户端发出的客户端标识符

   the registration process described by Section 2.2.

client_secret

<前><代码> 必需。客户秘密。客户端可以省略

   parameter if the client secret is an empty string.

OAuth 2.0 确实提供了其他方法，但通过选择这种方法，Facebook 完全符合规范。现在为什么 Facebook 选择这种方法，也许只有 Facebook 才能回答。

This is a requirement of the OAuth 2.0 spec, section 4.1.3.

If the client type is confidential or was issued client credentials
(or assigned other authentication requirements), the client MUST
authenticate with the authorization server as described in
Section 3.2.1

And section 3.2.1 refers to section 2.3. Specifically, section 2.3.1 says:

Alternatively, the authorization server MAY allow including the
client credentials in the request body using the following
parameters:

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.

There are indeed other ways OAuth 2.0 offers but by choosing this approach, Facebook is well within the spec. Now why Facebook opted for this approach, only Facebook can probably answer.

回复收藏 0 原文

雅心素梦 2024-12-11 04:39:56

除了 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）的组合提供了稍后与客户端凭据交换的信息

Beside being a requirement of Oauth2, the client_secret needs to be used in this step to verify you are indeed who you claim.

It all boils down to why the process is like it is...

The 'code' you get back from the first request is pretty weak from a security standpoint on it's own. It could hijacked on it's way back to you in the redirect link, which I've seen frequently go to landing pages without SSL protection. Even if you're 100% HTTPS thoughout your site, everything's not fully safe. Someone could find the code from looking at the request URLs which get logged inside your web server's access logs.

Even if you've got the tightest security environment this side of Buckingham Palace controlling access to you servers, if you've been riding the tech rodeo more than a few years, you know someone's going at some point 'archive' your logs somewhere less-than-ideally secure. Probably on a USB key they left behind at starbucks...

Nothing can be don't to avoid this if you're using a server side API flow. Unlike Javascript running inside the client browser, you can't have the temp code added after the hash to prevent it from being logged, because browser clients don't send anything past the hash mark with the request. JS can intercept the redirect Url, and parse out stuff after the Hash tag, that's why there is JS Oauth2 flow that simply returns the access_token with out the additional intermediary code song and dance. No Client_Secret need on the JS side either, which is good as it's generally frown upon when you put passwords and secret keys inside javascript.

Now, to prevent this intermediary code from being used by a bad guy to obtain an access token, the Client_ID and Client_Secret is sent along so the API server can authenticate you're the who you claim to be and you have the authorization to redeem the code for an access_token. Nothing beats a shared secret!

Since the code has a very short window of use before it expires--basically meant for you to redeem it for an access_token immediate--the danger of someone stealing code and trying to brute force a Client_Secret isn't too likely.

The combination of a short window of use and the client_secret (over ssl of course) provides a which you later exchange with you client credentials

回复收藏 0 原文

⊕婉儿 2024-12-11 04:39:56

请注意这几个字……不推荐。

2.3.1.客户端密码

拥有客户端密码的客户端可以使用 HTTP Basic
[RFC2617] 中定义的身份验证方案来进行身份验证
授权服务器。客户端标识符使用以下方式编码
“application/x-www-form-urlencoded”编码算法
附录B，编码值作为用户名；客户
密码使用相同的算法进行编码并用作
密码。授权服务器必须支持 HTTP Basic
用于验证已颁发的客户端的身份验证方案
客户端密码。

例如（带有额外的换行符仅用于显示目的）：

 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

或者，授权服务器可以支持包括
请求正文中的客户端凭据使用以下内容
参数：

client_id
必需的。期间向客户端发出的客户端标识符
第 2.2 节中描述的注册过程。

客户端秘密
必需的。客户秘密。客户端可以省略
如果客户端密钥是空字符串，则为参数。

使用这两个方法将客户端凭据包含在请求正文中
不建议使用参数，并且应仅限于无法使用的客户端
直接利用 HTTP Basic 身份验证方案（或其他
基于密码的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

授权服务器必须要求使用 TLS，如
1.6 节使用密码验证发送请求时。

由于此客户端身份验证方法涉及密码，因此
授权服务器必须保护任何使用它的端点
暴力攻击。

Notice the words.... NOT RECOMMENDED.

2.3.1. Client Password

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server. The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password. The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.

For example (with extra line breaks for display purposes only):

 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

Alternatively, the authorization server MAY support including the
client credentials in the request-body using the following
parameters:

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.

Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes). The parameters can only
be transmitted in the request-body and MUST NOT be included in the
request URI.

For example, a request to refresh an access token (Section 6) using
the body parameters (with extra line breaks for display purposes
only):

 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

The authorization server MUST require the use of TLS as described in
Section 1.6 when sending requests using password authentication.

Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against
brute force attacks.

回复收藏 0 原文

~没有更多了~