OAUTH2刷新令牌 [英] OAUTH2 Refresh Token
问题描述
我很少混淆OAuth2中的刷新令牌. 就像它说的那样，访问令牌限制了黑客可以使用用户凭据的1小时时间窗口，刷新令牌是长期有效的令牌，可以用来重新创建访问令牌.
I am little confuse of Refresh Token in OAuth2. Like it says access token limit the time window of 1 hour that hacker can use the user credentials and refresh token is long live token which can be use to recreate the access token.
如果有人从cookie中窃取了访问令牌，我也感到困惑，他还可以窃取刷新令牌，并且可以使用刷新令牌来创建新的访问令牌，因为我在JQuery(客户端)中有ajax请求
I am confused if someone stole the access token from cookie he can also stole the refresh token and can use the refresh token to create new access token as I have ajax request in JQuery (Client Side)
注意::我创建了一个ajax请求，以在服务器端发送刷新令牌，并在其中添加了客户端ID和Secret以及授予类型的刷新令牌.
NOTE: I have created ajax request to send refresh token on server side I append the Client ID and Secret there with grant type refresh token.
我已经在cookie中保存了访问令牌和刷新令牌，并在ajax请求之后使用以获取新的访问令牌
I have saved both access token and refresh token in cookie and use following the ajax request to get new access token
jQuery(document).ajaxError(function(event, jqXHR, ajaxSettings, thrownError) {
//console.log('event');console.log(event);
//console.log('jqXHR');console.log(jqXHR);
//console.log('ajaxSettings');console.log(ajaxSettings);
//console.log('thrownError');console.log(thrownError);
if(jqXHR.status == 403)
{
console.log('User is not Loged in Redictet to Login Page');
}
if(jqXHR.status == 401)
{
var refresh_token = Cookies.get('refresh_token');
if(refresh_token != undefined)
{
$.ajax({
url: CONNECT_API_URL+'/refresh-token',
type: "POST",
data:{ refresh_token: refresh_token },
success: function(response, status, jqXHR){
if(response.access_token != undefined)
{
var expires_in = new Date(new Date().getTime() + response.expires_in * 1000);
var access_token = response.token_type+' '+response.access_token;
Cookies.set('access_token', access_token, { expires: expires_in });
Cookies.set('refresh_token', response.refresh_token, { expires: 14 });
$.ajax(ajaxSettings); // Re send same ajax request with access token in cookie has been set
}
else
{
console.log('Redirect to login page.');
}
},
});
}
}
});
我应该如何使用刷新令牌来增强安全性?
How should I used refresh token to enhance the security?
推荐答案
Here on this blog post with the title Refresh Tokens: When to Use Them and How They Interact with JWTs the topic from your question is nicely discussed.
该帖子的引文:
刷新令牌通常受到严格的存储要求，以确保它们不会泄漏.
Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked.
在 RFC6819规范中，他们写了以下有关存储访问权限的内容客户端上的令牌:
In the RFC6819 spec they write the following about storing access tokens on the client:
5.1.6.访问令牌
应使用以下措施来保护访问令牌:
The following measures should be used to protect access tokens:
- 将它们保留在临时内存中(可由客户端访问) 仅限应用程序.)
- 使用安全传输(TLS)安全地传递令牌.
- 确保客户端应用程序不与3rd共享令牌 派对.
- Keep them in transient memory (accessible by the client application only).
- Pass tokens securely using secure transport (TLS).
- Ensure that client applications do not share tokens with 3rd parties.
关于刷新令牌的发行:
5.2.2.1.限制发行刷新令牌
授权服务器可以基于适当的策略来决定 不发行刷新令牌.由于刷新令牌是长期的 凭据，它们可能会被盗.例如，如果 授权服务器不信任客户端安全地存储此类内容 令牌，它可能会拒绝向此类客户端颁发刷新令牌.
The authorization server may decide, based on an appropriate policy, not to issue refresh tokens. Since refresh tokens are long-term credentials, they may be subject to theft. For example, if the authorization server does not trust a client to securely store such tokens, it may refuse to issue such a client a refresh token.
这意味着您可能应该仔细考虑要在何处存储刷新令牌.这篇文章 存储位置您的JWT – Cookies与HTML5 Web存储 恰好处理了这个主题.
This means you should probably think carefully on where you want to store your refresh tokens. This post Where to Store your JWTs – Cookies vs HTML5 Web Storage deals with exactly this topic.
也如在StackOverflow上的此答案中所述，仅refresh_token不足以获取新的access_token
As also mentioned in this answer on StackOverflow only the refresh_token is not enough to get a new access_token.
刷新令牌(如果遭到破坏)是无用的，因为攻击者除了需要刷新令牌之外还需要客户端ID和机密才能获得访问令牌.
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.
这也可以在相同的 RFC6819规范中找到:
This can also be found in that same RFC6819 spec:
5.2.2.2.刷新令牌与"client_id"的绑定
授权服务器应将每个刷新令牌与 签发给它的客户的标识符.授权 服务器应检查每个服务器是否都存在相同的"client_id" 请求刷新访问令牌.如果可能(例如，机密 客户端)，授权服务器应验证各自的身份 客户.
The authorization server should match every refresh token to the identifier of the client to whom it was issued. The authorization server should check that the same "client_id" is present for every request to refresh the access token. If possible (e.g., confidential clients), the authorization server should authenticate the respective client.
这是防止刷新令牌被盗或泄漏的对策.
This is a countermeasure against refresh token theft or leakage.
刷新令牌应仅使用一次.使用refresh_token时，它将返回一个新的access_token和一个新的refresh_token.它使旧的refresh_token无用，意味着它不再可以使用.
Refresh tokens should be used only once. When the refresh_token is used it will return a new access_token and a new refresh_token. It renders the old refresh_token useless meaning it can no longer be used.
它还允许身份验证服务器识别refresh_token被盗，因为它只能使用一次.如果使用相同的refresh_token发出新的续订请求，身份验证服务器将知道发生了一些混乱.虽然不确定服务器处理这种情况的正确方法是什么...(也许其他人可以对此有所启发)
It also allows the authentication server to recognize that a refresh_token was compromised, since it should only be used once. If a new renew request with the same refresh_token comes in the authentication server knows there is something fishy going on. Not sure what is the proper way for the server to deal with such a scenario though... (maybe someone else can shine some light on this)
这也在 RFC6819规范中:
5.2.2.3.刷新令牌轮换
刷新令牌轮换旨在自动检测并 防止尝试从以下位置并行使用同一刷新令牌 不同的应用程序/设备.如果令牌从 客户端，随后被攻击者和 合法客户.基本思想是更改刷新令牌 每个刷新请求的值，以检测尝试 使用旧的刷新令牌获取访问令牌.自从 授权服务器无法确定攻击者还是攻击者 合法客户端正在尝试访问，如果有这样的访问 尝试有效的刷新令牌和访问授权 与之关联的两者都被撤销.
Refresh token rotation is intended to automatically detect and prevent attempts to use the same refresh token in parallel from different apps/devices. This happens if a token gets stolen from the client and is subsequently used by both the attacker and the legitimate client. The basic idea is to change the refresh token value with every refresh request in order to detect attempts to obtain access tokens using old refresh tokens. Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked.
OAuth规范支持此措施，因为令牌的 响应允许授权服务器返回新的刷新 令牌，甚至对于授权类型为"refresh_token"的请求也是如此.
The OAuth specification supports this measure in that the token's response allows the authorization server to return a new refresh token even for requests with grant type "refresh_token".
注意:此措施可能会在群集环境中引起问题， 因为必须确保使用当前有效的刷新令牌.在 这样的环境，其他措施可能更合适.
Note: This measure may cause problems in clustered environments, since usage of the currently valid refresh token must be ensured. In such an environment, other measures might be more appropriate.
您的访问令牌和刷新令牌可能在客户端上受到破坏，但令牌也可能在客户端和服务器之间的某个地方被拦截.
refresh_token仅发送一次给客户端，而access_token随每个请求发送到服务器，这就是为什么中间人将手伸到access_token上的机会很大那么您的refresh_token受到威胁的机会就更大.
Your access and refresh tokens can be compromised on the client but the tokens could also be intercepted somewhere in between your client and the server.
The refresh_token is sent only once to a client while the access_token is being sent to the server with every request, that is why the chances of a man-in-the-middle getting his hands on your access_token are much bigger then the chance that your refresh_token is compromised.
通常，最好完全了解OAuth2协议，以便您可以正确实现它.关于安全性，我想简单地说:
In general it is good to fully understand the OAuth2 protocol so that you can properly implement it. About the security I would say in short:
- 使用JWT的首要要求是客户端和服务器之间正确配置的https连接，以便在来回发送所有令牌时对其进行正确加密.
- 第二次需求是您以安全的方式将令牌存储在客户端上.
- A first demand for using JWTs is a properly configured https connection between your client and the server so that all the tokens are properly encrypted when they are sent back and forth.
- A second demand is that you store the tokens in a secure way on your client.
我希望这可以使您对该主题有所了解.如果有人想添加或更正我的帖子，请随时编辑/更新/完善答案或发表评论.
这篇关于OAUTH2刷新令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
