Wir verwenden das Benutzernamen-Passwort-Grant, um unseren JS-Client mit unserem REST-Server zu verbinden. In gewisser Weise ist das von oauth / token zurückgegebene Token unsere Sitzung, da es für eine begrenzte Zeit den Zugriff auf das Backend ermöglicht.

Wir möchten diese Sitzung / dieses Token jedes Mal aktualisieren, wenn wir mit dem Token eine Anforderung an das Backend senden.

Ich weiß, dass dieses Aktualisierungstoken vom Server ausgegeben wird, und ich könnte es verwenden, um mein Token nach dessen Ablauf zu aktualisieren.

Die Sache ist: Ich möchte nicht, dass der Client für das Abfangen einer abgelaufenen Token-Ausnahme und das erneute Authentifizieren oder Planen einer Aktualisierung vor dem Ablauf des Token verantwortlich ist. Ich möchte, dass sich das Token selbst aktualisiert, bis es für eine begrenzte Zeit nicht mehr verwendet wird - genau wie eine Sitzung. (Ich möchte auch nicht, dass es bei jeder "Daten" -Anforderung eine Aktualisierungsanforderung ausgibt, obwohl ich mich daran erinnere, dass ich gelesen habe, dass ein Aktualisierungs-Token nur einmal gültig ist.?!)

Gibt es eine Möglichkeit, dies im Frühjahr zu tun, oder muss ich eine benutzerdefinierte Implementierung des Token-Speichers oder eines von mir ausgewählten Teils erstellen?

Da ich keine richtige Antwort finden kann (daher der Beitrag), denke ich: Vielleicht ist es nicht ratsam, dies zu tun, obwohl ich mir nicht vorstellen kann, warum. Wenn ich das Token stehlen kann, kann ich auch das Aktualisierungstoken stehlen. Ich denke also, ich sehe nicht wirklich den Sinn darin, überhaupt einen Refresh-Token zu haben.

BEARBEITEN

Als Antwort auf Luke Taylors Antwort werde ich unseren Anwendungsfall klarstellen.

Wir haben einen REST-Server, der Anwendungsdaten wie Personen enthält. bietet aber auch Zugriff auf unser Content-Management und ermöglicht es Kunden, auf Facebook zu posten. Es kapselt Anwendungslogik und DatenspeicherungWir haben bereits eine vollwertige Client-Anwendung, die über eine eigene Sicherheitsschicht verfügt und über den Client-Anmeldeinformationsfluss auf die Daten auf unserem REST-Server zugreift. Wer was kann, entscheidet der AuftraggeberWir haben mehrere mittlere und kleine Anwendungen wie eine Kontakt-App auf Facebook, die auf die Daten auf dem REST-Server auch mit Client-Anmeldeinformationen zugreifenWir entwickeln derzeit eine Clientanwendung, die nur JavaScript verwendet und auf die REST-Ebene zugreift, um alle Aufgaben der großen Clientanwendung zu erledigen. Sie muss jedoch auch die Möglichkeit bieten, einzelne Benutzer zu authentifizieren und eine Mandantenfähigkeit zu ermöglichen. Daher verwendet diese neue Clientanwendung die Berechtigung "Benutzername-Kennwort" zur Authentifizierung und die Sicherheit auf Methodenebene zur Autorisierung der Benutzer

Wir haben also einen REST-Server, der vollständigen Zugriff auf unsere vertrauenswürdige Anwendung bereitstellen muss, die ihre eigenen Sicherheitsaufgaben erledigt, und denselben Server, der den Benutzern unserer neuen mandantenfähigen JavaScript-Client-Anwendung Zugriff gewähren muss. In der Produktion werden wir mehrere REST-Server mit jeweils einer eigenen Datenbank haben, aber der Kern wird immer derselbe sein, sodass theoretisch ein Server in der Lage sein sollte, alle zu verarbeiten.