获取新的访问令牌时,不应替换oauth2中的刷新令牌 [英] Refresh tokens in oauth2 should not be replaced when getting a new access token

查看:355
本文介绍了获取新的访问令牌时,不应替换oauth2中的刷新令牌的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

标题中的陈述正确吗?我将问题基于Taiseer Joudeh所做的工作(感谢您在这个问题上的工作,顺便说一句),位于

Is the statement in the title correct? I'm basing the question on the work done by Taiseer Joudeh (thanks for your work on this subject, btw) at http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/.

如果我正确理解了刷新令牌的行为,那么当访问令牌过期时,我们应该使用类似的方式调用身份验证服务器的令牌端点

If I understand the behavior of refresh tokens correctly, when an access token expires, we should call the token endpoint of our auth server with something like

'grant_type=refresh_token&refresh_token=' + token

,我们将取回新的访问令牌.该请求将有一个刷新令牌作为有效负载的一部分,但是该刷新令牌不应该与我们刚刚使用的令牌相同吗?或者至少,它应该具有相同的到期时间?如果没有,那么刷新寿命实际上是无限的.

and we will get back a new access token. That request will have a refresh token as part of the payload, but shouldn't that refresh token be the same one we just used? Or at the very least, it should have the same expiration? If not, then really, the refresh lifetime is infinite.

这是我希望通过的frisby.js测试,但是使用针对Web Api 2的Taiseer实现,最终的期望失败了.我们获得了一个新的刷新令牌,该令牌具有新的到期时间.

Here are the the frisby.js tests I would expect to pass, but using Taiseer's implementation for Web Api 2, the final expectation fails. We get a new refresh token with a new expiration on that token.

'use strict';

var frisby = require('frisby');
var config = require('../test-config.json');

var args = config[process.env.test || 'local'];
var host = args.host,
    clientId = args.clientId,
    usr = args.user1,
    pwd = args.password1;

frisby.create('Try and fail to get a protected resource')
    .get(host + '/api/test')
    .expectStatus(401)
    .expectHeaderContains('WWW-Authenticate', 'bearer')
    .toss();

frisby.create('Log in and get a protected resource')
    .post(host + '/token', {
        grant_type: 'password',
        username: usr,
        password: pwd,
        client_id: clientId
    })
    .expectJSONTypes({
        access_token: String,
        token_type: String,
        expires_in: Number,
        userName: String,
        refresh_token: String,
        'as:client_id': String,
        '.issued': String,
        '.expires': String
    })
    .expectJSON({
        token_type: 'bearer',
        userName: 'test2@test.com'
    })
    .afterJSON(function (json) {
        frisby.create('and now get protected resource with attached bearer token')
            .get(host + '/api/test', {
                headers: { 'Authorization': 'Bearer ' + json.access_token }
            })
            .expectStatus(200)
            .toss();
        frisby.create('and try to get a new access token with our refresh token')
            .post(host + '/token', {
                grant_type: 'refresh_token',
                refresh_token: json.refresh_token,
                client_id: clientId
            })
            .afterJSON(function (json2) {
                //we should receive a new access token
                expect(json.access_token).not.toEqual(json2.access_token);
                //but shouldn't the refresh token remain the same until *it* expires?
                expect(json.refresh_token).toEqual(json2.refresh_token);
            })
            .toss();
    })
    .toss();

推荐答案

您是100%正确的,当前刷新令牌的实现对于刷新令牌具有滑动到期时间,因为对于Grant_type = refresh_token的每次使用,我们都在发行新的访问令牌和刷新令牌标识符,这对于我的情况来说是完美的,因为我希望用户只要使用该应用程序就可以永久登录,如果他不使用该应用程序的时间超过刷新的到期日期令牌,那么当他尝试使用刷新令牌获取新的访问令牌时,他将收到401.

You are 100% correct, the current implementation of refresh token has sliding expiration for the refresh token because with each use for grant_type=refresh_token we are issuing new access token and refresh token identifier, and this was perfect for my case because I want the user to be logged in forever as long as he is using the application, if he didn't use the application for a period greater then the expiration date for the refresh token then he will receive 401 when he tries to obtain new access token using the refresh token.

要更改此行为,您只需要发布单个刷新令牌标识符,并在用户使用刷新令牌请求新的访问令牌时返回相同的标识符.您也可以通过自定义这种方法中的业务逻辑来做到这一点.

To change this behavior you need to issue only single refresh token identifier and return the same identifier when the user asks for new access token using the refresh token. And you can do this by customizing the business logic in this method and this too.

这篇关于获取新的访问令牌时,不应替换oauth2中的刷新令牌的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆