我应该在 OAuth 2.0 中发送带有刷新令牌的秘密吗

Question

我正在努力实现 OAuth 2.0 服务器，在阅读 RFC6749 规范时，我意识到 section 6 on Page 47 关于“刷新访问令牌”。说明我们只需要使用 Refresh Token 就可以得到一个新的 Token。

但是例如，除了刷新令牌之外，Google 还需要用户 ID 和密码才能这样做。

这让我很困惑，因为一方面我们的 Google 每天都在处理大量请求，而且我们编写的规范可能考虑的范围更小。

使用 Refresh Token 每小时发送一次 Secret 好不好？

我个人认为不会：因为用户 ID 和机密应该只用于检查整个 OAuth 2.0 过程。

基本上

1. 您在每个请求中使用令牌来证明您就是您。
2. 刷新令牌每小时只使用一次（每次刷新时可能会更改）
3. 秘密和用户 ID 尽可能少地访问 Internet。 Only when option 1 and 2 get compromised.

我个人认为使用 Refresh 令牌发送 Secret 的安全性较低。但也许我错过了什么。

如果你有其他观点，请分享:)

Answer 1

我可能遗漏了一些东西，但Google 要求以及 OAuth2 还指定的是，当从机密客户端应用程序刷新令牌时，客户端必须对自身进行身份验证。

用于机密客户端的最常见凭据类型是客户端标识符和客户端密码。此信息发布给客户端应用程序，与最终用户无关。

通过要求客户端身份验证，授权服务器可以确定请求来自特定客户端并相应地调整其响应。例如，授权服务器可以决定某些权限（范围）只能从机密客户端请求。

关于减少需要通过网络发送客户端密码的次数的论点不是问题。 OAuth2 要求通过 TLS 进行通信，如果您在发送密钥时遇到问题，那么您在发送不记名访问令牌时也会遇到问题。

总之，虽然有时完全按照规范做事而不质疑整体情况可能会导致漏洞：

... 一些库将使用none 算法签名的令牌视为具有经过验证的签名的有效令牌。结果？任何人都可以使用他们想要的任何有效负载创建自己的“签名”令牌，从而允许在某些系统上进行任意帐户访问。

（来源：Critical vulnerabilities in JSON Web Token libraries）

一些库按照规范处理none算法，但忽略了使用上下文；如果开发人员传递了一个密钥来验证签名，它很可能不想将未签名的令牌视为有效。

但是，在刷新令牌请求中传递秘密不是这些情况之一，所以不用担心。