为什么OAuth v2有访问和刷新令牌？(Why Does OAuth v2 Have Both Access and Refresh Tokens?)

为什么OAuth v2有访问和刷新令牌？(Why Does OAuth v2 Have Both Access and Refresh Tokens?)

OAuth 2.0协议草案的第4.2节指出，授权服务器可以同时返回一个access_token （用于向资源进行身份验证）以及一个refresh_token ，该文件纯粹用于创建一个新的access_token ：

https://tools.ietf.org/html/rfc6749#section-4.2

为什么有两个？ 为什么不使access_token最后一次只要refresh_token并且没有refresh_token ？

Section 4.2 of the draft OAuth 2.0 protocol indicates that an authorization server can return both an access_token (which is used to authenticate oneself with a resource) as well as a refresh_token, which is used purely to create a new access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

Why have both? Why not just make the access_token last as long as the refresh_token and not have a refresh_token?

最满意答案

刷新令牌的想法是，如果访问令牌受到威胁，因为它是短暂的，攻击者有一个有限的窗口来滥用它。

刷新令牌（如果受到损害）是无用的，因为除了刷新令牌之外，攻击者还需要客户端ID和密码，以获得访问令牌。

话虽如此 ，因为通过SSL完成对授权服务器和资源服务器的每次调用，包括原始客户机ID和密钥，当它们请求访问/刷新令牌时，我不确定访问令牌是如何进一步“长寿命刷新令牌和客户端/秘密组合。

这当然不同于您不控制授权和资源服务器的实现。

这是一个很好的主题，关于刷新令牌的使用： OAuth Archives 。

从上面引用，谈到刷新令牌的安全性：

刷新令牌...减轻长时间访问_漏洞的风险（在不安全的资源服务器，测试版或编码不足的资源服务器应用程序的日志文件中的查询参数，在非https站点上的JS SDK客户端，将access_token置于曲奇等）

The idea of refresh tokens is that if an access token is compromised, because it is short-lived, the attacker has a limited window in which to abuse it.

Refresh tokens, if compromised, are useless because the attacker requires the client id and secret in addition to the refresh token in order to gain an access token.

Having said that, because every call to both the authorization server and the resource server is done over SSL - including the original client id and secret when they request the access/refresh tokens - I am unsure as to how the access token is any more "compromisable" than the long-lived refresh token and clientid/secret combination.

This of course is different to implementations where you don't control both the authorization and resource servers.

Here is a good thread talking about uses of refresh tokens: OAuth Archives.

A quote from the above, talking about the security purposes of the refresh token:

Refresh tokens... mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc)