Ich entwickle den Authentifizierungsfluss einer Einzelseitenanwendung (AngularJS + .Net MVC Json Rest API) mithilfe von Owin Oauth2 (Autorisierungs- und Ressourcenserver sind identisch).

Ich habe die Bearer-Token-Route der traditionellen Cookie + -Sitzung vorgezogen, weil ich staatenlos bleiben möchte und weil dieselbe API von einer mobilen App verwendet wird, bei der das Token weniger Probleme hat als das Cookie.

Dies ist der vereinfachte Ablauf:

User übermittelt Benutzername / Passwort an den Server (POST über HTTP an die TokenProvider-Route)Owin erstellt einAccessToken mit einem Anspruch, der eine generierte GUID (die so etwas wie eine Sitzungs-ID darstellt) und einige andere Ansprüche enthält.Owin erstellt einRefreshToken.Server erstellt einen Eintrag imRefreshToken Tabelle mit folgenden Feldern:

GUID (PK) | RefreshToken | Ticket | DateIssued | DateExpire | DateEnd

Server gibt sowohl dasAccessToken und dieRefreshToken an den Client

Client speichert sowohl dasAccessToken undRefreshToken in den SessionStorage.

Client greift mit dem @ auf das Api AccessToken.

Wenn AngularJS feststellt, dass das AccessToken in der Nähe des Ablaufs ist, puffert es alle Anforderungen und gibt ein @ augrant_type refresh_token request;
server verwendet dasRefreshToken vom Kunden bereitgestellt und:

Überprüft, ob das Refresh Token von Db noch gültig ist DateExpire > GetTime() And DateEnd is Null)Nimmt das Ticket von Db Erstellt ein AccessToken aus Ticket Aktualisiert den Datenbankeintrag mit den neuen Daten, dem neuenRefreshToken und das neue Ticket (Hinweis: Die GUID bleibt gleich)

Wenn der Client die Abmeldeserverseite erreicht, wird die aus dem Identitätsanspruch des angemeldeten Benutzers gelesene GUID verwendet, um den Eintrag in der Tabelle ungültig zu machen DateEnd = GetTime()).
Client-Seite beide Token werden aus dem @ entferSessionStorage.

uf diese Weise kann ich das @ widerrufRefreshToken andere Anfragen ablehnen, um ein neues @ zu erhaltAccessToken.

Das Problem bei diesem Ansatz ist, dass es ein Zeitfenster gibt, in dem die Autorisierung widerrufen wird (dh:RefreshToken auf DB ungültig gemacht), aber dasAccessToken ist immer noch gültig (obwohl für einen begrenzten Zeitraum).

Was ich denke zu tun ist, um die Gültigkeit des @ zu überprüfAccessToken Bei jeder Anforderung wird die GUID aus den Benutzeridentitätsansprüchen entnommen und die Datenbank aufgerufen, um zu prüfen, ob das Aktualisierungstoken dieser bestimmten GUID noch gültig ist.

bwohl es ziemlich trivial ist, Abfragen mit O (1) auszuführen, kann der einzelne Fehlerpunkt selbst negative Auswirkungen auf die Skalierbarkeit und Leistung des Systems habe

Kennen Sie eine andere Methode, um dieses Problem zu beheben, und sehen Sie Fehler in meinem Ansatz?