我应该使用OAuth 2.0中的刷新令牌发送秘密

Question

我正在努力实现OAuth 2.0服务器，并且在阅读RFC6749规范时，我意识到有关“刷新访问令牌”的section 6 on Page 47。解释我们需要使用刷新令牌来获得新的令牌。

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

这使我很困惑，因为一方面我们有Google每天处理大量请求的情况，而且我们有一个可能写入规范的规范，可能在考虑范围较小的情况下。

每个小时都用Refresh Token发送秘密是否好？

就我个人而言，我认为不可以：因为User ID和Secret只能用于整个OAuth 2.0流程。

基本上

1. 您使用对每个请求令牌来证明你是你是谁。
2. 刷新令牌每小时只能使用一次（并且在每次刷新时可能会更改）
3. 秘密和用户ID尽可能少地上网。只有当选项1和2受到损害时。

我个人认为发送带有刷新令牌的秘密不太安全。但也许我错过了一些东西。

如果你有另一种观点，请分享:)

Answer 1

我可能失去了一些东西，但是谷歌需要的，什么是还通过了OAuth2规定是从一个保密的客户端应用程序刷新令牌时，客户端必须认证自己。

用于机密客户端的最常见类型的凭证是客户端标识符以及客户端密钥。该信息发布给客户端应用程序，与最终用户无关。

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

围绕减少客户机密码需要通过线路发送的次数的争论是非问题。 OAuth2强制通信发生在TLS上，如果您在发送密钥方面存在问题，那么您也会在发送承载访问令牌时遇到问题。

总之，虽然有时候做事情完全按规范没有质疑的总体背景下可能导致漏洞：

...拥有经过验证的处理与none算法签署令牌为有效令牌一些图书馆签名。结果？任何人都可以用他们想要的任何有效载荷创建自己的“签名”令牌，允许在某些系统上任意访问帐户。

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

某些库，按照规范处理的none算法，而忽视了惯用法上下文;如果开发人员通过密钥来验证签名，它很可能不想将未签名的令牌视为有效。

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