Los tokens de actualización en oauth2 no deberían reemplazarse al obtener un nuevo token de acceso: oauth, refresh, token, asp.net-web-api2

¿Es correcta la afirmación en el título? Estoy basando la pregunta en el trabajo realizado por Taiseer Joudeh (gracias por su trabajo en este tema, por cierto) en http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/.

Si entiendo correctamente el comportamiento de los tokens de actualización, cuando caduque un token de acceso, deberíamos llamar al punto final del token de nuestro servidor de autenticación con algo como

"grant_type=refresh_token&refresh_token=" + token

y recuperaremos un nuevo token de acceso. Esa solicitud tendrá un token de actualización como parte de la carga útil, pero ¿no debería ser el mismo token de actualización que acabamos de usar? O, como mínimo, debería tener la misma caducidad? Si no es así, entonces realmente, la duración de la actualización es infinito.

Estas son las pruebas de frisby.js que esperaría aprobar, pero al usar la implementación de Taiseer para Web Api 2, la expectativa final falla. Recibimos un nuevo token de actualización con un nuevo vencimiento en ese 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();

Respuestas

Eres 100% correcto, la implementación actual.token de actualización tiene vencimiento deslizante para el token de actualización porque con cada uso para grant_type = refresh_token estamos emitiendo un nuevo token de acceso y un identificador del token de actualización, y esto fue perfecto para mi caso porque quiero que el usuario inicie sesión por siempre, siempre y cuando está usando la aplicación, si no la usó por un período mayor a la fecha de vencimiento del token de actualización, entonces recibirá 401 cuando intente obtener un token de acceso nuevo usando el token de actualización.

Para cambiar este comportamiento solo necesitas emitiridentifique el identificador del token de actualización y devuelva el mismo identificador cuando el usuario solicite un nuevo token de acceso utilizando el token de actualización. Y puede hacer esto personalizando la lógica de negocios en este método y esto también.