Refresh-Token in oauth2 sollten nicht ersetzt werden, wenn ein neues Access Token erhalten wird

Question

Ist die Aussage im Titel korrekt? Ich stütze die Frage auf die Arbeit von Taiseer Joudeh (danke für Ihre Arbeit zu diesem Thema, btw) unter http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/.

Wenn ich das Verhalten der Refresh-verstehen-Token korrekt, wenn ein Zugriffstoken abgelaufen ist, sollten wir das Token-Endpunkt unserer Auth-Server mit so etwas wie

'grant_type=refresh_token&refresh_token=' + token 

nennen und wir werden einen neuen Zugriffstoken zurück. Diese Anforderung enthält ein Aktualisierungstoken als Teil der Nutzlast. Soll das Aktualisierungs-Token jedoch nicht dasselbe sein, das wir gerade verwendet haben? Oder zumindest sollte es den gleichen Ablauf haben? Wenn nicht, dann ist die Lebensdauer der Aktualisierung unendlich.

Hier sind die frisby.js Tests, die ich erwarten würde, aber mit Taiiseer Implementierung für Web Api 2, schlägt die endgültige Erwartung fehl. Wir erhalten ein neues Aktualisierungstoken mit einem neuen Ablaufdatum für dieses 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(); 

Answer 1

Sie sind 100% richtig, ist die aktuelle Implementierung von Aktualisierungs-Token sind mit jedem Gebrauch, da für die Aktualisierungs-Token gleitenden Ablauf für grant_type = refresh_token wir neue Zugriffstoken und Aktualisierungs-Token-Kennung erteilen, und das war perfekt für Mein Fall, weil ich möchte, dass der Benutzer für immer angemeldet ist, solange er die Anwendung verwendet, wenn er die Anwendung nicht länger als das Ablaufdatum des Aktualisierungstokens verwendet hat, dann erhält er 401, wenn er versucht Ermitteln eines neuen Zugriffstokens mithilfe des Aktualisierungstokens.

Um dieses Verhalten zu ändern, müssen Sie nur eine einzelne Aktualisierungstokenkennung ausgeben und dieselbe Kennung zurückgeben, wenn der Benutzer mit dem Aktualisierungstoken nach einem neuen Zugriffstoken fragt. Und Sie können dies tun, indem Sie die Geschäftslogik in dieser Methode anpassen und dies auch.