Killing "Sitzung" mit SignalR, OWIN und Web API

Question

Es war ein langer Weg, aber ich habe SignalR arbeiten mit meiner Web-API, die OWIN für Token-Authentifizierung verwendet.

Ich habe einen Mechanismus, wo, wenn ein Benutzer auf Terminal # 1 authentifiziert und später auf Terminal # 2 authentifiziert, kann ich ihnen eine Javascript-Warnung sagen "Hey, nur eine Sitzung zu einer Zeit. Welche wollen Sie Ausloggen?"

Die Frage, die ich habe, ist, wie man ihre "Sitzung" auf einem der Terminals zu töten? Ich sage "Sitzung", aber da dies eine REST-basierte API ist, gibt es wirklich keine Sitzung. Wenn ich sie dazu zwingen könnte, sich erneut am Terminal zu authentifizieren, würde es ausreichen, wenn sie sich ausloggen.

Ich habe das SignalR connectionId von jedem Client. Gibt es eine Möglichkeit, wie ich ihr Authentifizierungs-Token ablaufen lassen und eine Abmeldung erzwingen kann?

Hinweis - Der Client ist von der Web-API insofern getrennt, als er auf zwei verschiedenen Servern gehostet wird. Der Client ist nur HTML/Javascript, das Aufrufe an die Web-API aufruft.

Answer 1

Wenn Sie einen Träger Token Ansatz verwenden, und Sie speichern nicht Token (oder Token-Hashes) in eine Art permanenten Speicher (zum Beispiel ein DB), dann haben Sie keine Möglichkeit zu Invalidier ein Token.

Seit OAuth is not an Authentication protocol, hat es keine Art von log out Konzept darin. Ihre einzige Option besteht darin, das Token aus dem Client-Speicher zu entfernen (ich kann mir vorstellen, dass es im localStorage oder in einem Cookie gespeichert ist).

Natürlich macht dies nichts wirklich ungültig, und wenn das Token aus irgendeinem Grund nicht gelöscht wird, kann es weiterhin für Autorisierungszwecke verwendet werden.

Wenn Sie wirklich nur ein einmal gültiges Zugriffstoken benötigen, können Sie nur einige Informationen darüber in einer Datenbank speichern und diesen Speicher jedes Mal überprüfen, wenn Sie das Token validieren. Sie könnten zum Beispiel den Hash des Tokens speichern (niemals das echte Token für this reason speichern, sie haben denselben Wert wie einmal gespeicherte Passwörter) mit dem Benutzernamen, aber beachten Sie, dass dieser Ansatz Ihr Autorisierungsprotokoll etwas weniger statuslos macht als vorher.