Session-Management mit JSON-Web-Token in Microservices

Question

Ich versuche herauszufinden, wie ich Sitzungen mit JSON-Web-Token in einer Microservice-Architektur verwalten werde.

Mit Blick auf das Design in diesem article was ich derzeit im Auge habe ist, dass der Client eine Anfrage senden wird, die zuerst durch eine Firewall geht. Diese Anfrage enthält ein Opak-/Referenz-Token, das die Firewall an einen Autorisierungsserver sendet. Der Autorisierungsserver antwortet mit einem Wert-Token, das alle Sitzungsinformationen für den Benutzer enthält. Die Firewall übergibt die Anforderung dann zusammen mit dem Wert-Token an die API, und das Wert-Token wird dann an alle verschiedenen Microservices weitergegeben, die zur Erfüllung der Anforderung erforderlich sind.

Ich habe 2 Fragen:

1. Wie Aktualisierungen der Sitzungsinformationen im Wert Token behandelt werden sollte? Wenn die Sitzungsinformationen in einem Token aktualisiert werden, müssen diese auf dem Autorisierungsserver aktualisiert werden. Sollte jeder Dienst, der das Token ändert, mit dem Autorisierungsserver sprechen?
2. Sollten alle Microservices dieses einzelne Token verwenden, um ihre Sitzungsinformationen zu speichern? Oder wäre es für jeden Dienst besser, ein personalisiertes Token zu haben? Wenn es das letztere ist, erklären Sie bitte, wie man das Design justiert.

Answer 1

Ein sehr bezeichnend für diese Art von Design „in der Suppe fliegen“ ..., die vorab auf Ihrer Seite dachte vorsichtig erfordert ... ist (!): “ genau was von ‘ Sitzung gemeint ist ’ Information. ” In dieser Architektur, “ ist jeder Racing mit allen anderen. ” Wenn die Sitzungsinformationen aktualisiert sind, können Sie nicht und grundsätzlich nicht (!) Wissen, welche der Agenten über diese Änderung weiß und welche nicht. Um die Dinge noch komplizierter zu machen, werden neue Anfragen asynchron eintreffen und andere Anfragen auf unvorhersehbare Weise überlappen.

Daher muss der Authorization Server genau das sein ... und nicht mehr. Es validiert (authentifiziert ...) das opake Token und liefert eine vertrauenswürdige Beschreibung dessen, was die Anfrage autorisiert zu tun ist. Aber die Informationen, die es beherbergt, können sich grundsätzlich nicht ändern. Und genau gesagt kann es “ Sitzungsstatus ” Daten im Web-Server Sinn dieses Begriffs nicht halten.

Jeder Micro Provider muss seine eigene “ Trageplatte ” * (meinen Begriff ... “ seine besondere Untergruppe von dem, was in einem Web-Server wäre ‘ ’ ” der Sitzungspool), und es ist wünschenswert halten aber nicht immer möglich, dass sein Brett unabhängig von den anderen wäre. Fast sicher muss es eine zentrale Datenbank (mit Transaktionen) verwenden, um sich mit anderen ähnlich positionierten Dienstleistern zu koordinieren. Und trotzdem, wenn die Wahrheit ist, dass der Inhalt eines dieser “ Totes ” ursächlich mit einem anderen verwandt ist, haben Sie jetzt ein Problem nicht synchron zwischen ihnen.

Obwohl Micro Architektur einen gewissen akademischen Reiz hat, muss IMHO Design seiner sorgfältig sicher sein, untersuchte, dass sie in der Tat mit diesem Ansatz kompatibel.