Ich erstelle eine Reihe von Web-Apps, die mit einem einzigen Authentifizierungspunkt verbunden sind. Grundsätzlich versucht ein Benutzer, auf eine Site zuzugreifen. Wenn er nicht authentifiziert ist, wird er auf die Anmeldeseite des zentralen Authentifizierungssystems umgeleitet. Sobald sie sich erfolgreich angemeldet haben, werden sie zu ihrer App weitergeleitet. Wenn sie von da an auf eine andere App zugreifen, werden sie automatisch angemeldet.
Ein paar zusätzliche Details: 1) Die Apps werden alle unter derselben Domain ausgeführt, sodass ich Domain-Cookies verwenden kann, was die Sache einfacher macht. 2) Benutzern kann Zugriff auf einige Apps und nicht auf andere gewährt werden, sodass dies berücksichtigt werden muss. 3) Der Benutzer muss in der Lage sein, für jede App spezifische Berechtigungen abzurufen.
Ich habe etwas implementiert, bin aber nicht 100% zufrieden damit. Im Moment habe ich Folgendes: 1) Die Web-App prüft, ob eine Sitzung (spezifisch für die App) und ein Cookie vorhanden sind, bei dem es sich um ein JWT-Token handelt, das vom zentralisierten Authentifizierungssystem gesendet wurde. 2) Wenn kein Cookie vorhanden ist, leite ich zur Anmeldeseite des Authentifizierungssystems weiter. 3) Sobald sich der Benutzer anmeldet, wird er zu seiner App umgeleitet, die ein JWT-Token übergibt. 4) Die App überprüft das Token über einen REST-API-Aufruf an das Authentifizierungssystem (für diese REST-API-Aufrufe ist ein separates Zugriffstoken erforderlich). Wenn es gültig ist, wird das JWT-Token als Cookie gespeichert und eine Sitzung mit dem initiiert Benutzer angemeldet; 5) Wenn die App-Sitzung abläuft, prüft sie, ob das Cookie vorhanden ist. Wenn dies der Fall ist, führt die App dasselbe wie in Schritt 4 aus, überprüft das Token und startet die Sitzung erneut. 6) Beim Abmelden löscht das System nur das Cookie. Sicherstellen, dass der Benutzer von allen Apps abgemeldet ist; 7) Wenn das Token abläuft, verwendet die App das abgelaufene Token, um ein neues Token anzufordern, bei dem die Tokensignatur und andere Ansprüche vor der Ausstellung eines neuen validiert werden. Das einzige, was nicht validiert wird, ist der Ablaufanspruch.
Zur Verdeutlichung wird das Vorhandensein einer für die App spezifischen Sitzung verwendet, damit Sie nicht ständig REST-API-Aufrufe durchführen müssen, um das Token zu überprüfen. Wäre es angesichts der einmaligen Überprüfung des Tokens sicher, dieses Cookie nur als Indikator für eine gültige Sitzung zu verwenden?
Eine Sache, bei der ich mir nicht sicher bin, ist, dass mein Token etwas haben muss, das angibt, für welche App es ist, da andere REST-API-Aufrufe mithilfe des Tokens durchgeführt werden können, um einige Ressourcen abzurufen, die app-spezifisch sind. Wenn ich jedoch ein Token für App1 erhalte und mich dann bei App2 anmelde, verlässt sich App2 auf das von App2 generierte Cookie. Es scheint also, als würde ich zwei Token haben wollen, eines, das als Domain-Cookie gespeichert werden kann, um anzuzeigen, dass der Benutzer authentifiziert ist, und ein anderes, das tatsächlich app-spezifisch ist und zum Ausführen von REST-API-Aufrufen für andere Apps verwendet werden kann. spezifische Ressourcen.
Kompliziere ich das zu sehr oder stimmt meine Denkweise mit dem überein, was andere da draußen sehen / tun? Oder gibt es eine elegantere Möglichkeit, dies zu tun? Ich habe darüber nachgedacht, so etwas wie Open ID zu implementieren, aber es scheint ein bisschen übertrieben für unsere Bedürfnisse zu sein. Ich möchte, dass dies so einfach wie möglich ist, damit ich den Prozess dokumentieren kann und andere Entwicklerteams Apps entwickeln können, die sich in das Authentifizierungssystem einbinden lassen, ohne zu viel Unterstützung zu benötigen.