it-swarm.com.de

Single Sign-On-Flow unter Verwendung von JWT für die domänenübergreifende Authentifizierung

Im Internet gibt es viele Informationen über die Verwendung von JWT (Json Web Token) zur Authentifizierung. Aber ich habe immer noch keine klare Erklärung gefunden, wie der Ablauf aussehen soll, wenn JWT-Token für eine Single Sign-On-Lösung in einer Umgebung mit mehreren Domänen verwendet werden.

Ich arbeite für ein Unternehmen, das viele Websites auf verschiedenen Hosts hat. Verwenden wir example1.com und example2.com. Wir benötigen eine Single Sign-On-Lösung. Wenn sich ein Benutzer also bei example1.com authentifiziert, soll er auch bei example2.com automatisch authentifiziert werden.

Unter Verwendung des OpenId Connect -Flusses wird der Benutzer, der sich auf example1.com authentifizieren möchte, zunächst an den Authentifizierungsserver (oder weitergeleitet OP: "OpenId Provider"). Der Benutzer authentifiziert sich auf diesem Server, der ihn dann mit einem signierten JWT-Token zur ursprünglichen example1.com -Site zurückleitet. (Ich verstehe, dass es einen anderen Fluss gibt, der ein intermediäres Token zurückgibt, das später gegen das echte JWT-Token ausgetauscht werden kann, aber ich denke nicht, dass dies für uns erforderlich ist.) ...

Nun ist der Benutzer wieder auf example1.com und authentifiziert! Er kann Anforderungen stellen, indem er das JWT-Token in einem Authentication -Header übergibt, und der Server kann das signierte JWT überprüfen und somit den Benutzer identifizieren. Nett!

Erste Frage:

Wie soll das JWT-Token auf dem Client gespeichert werden? Es gibt wieder viele Informationen darüber, und die Leute scheinen zuzustimmen, dass die Verwendung von Web Storage ist eher der richtige Weg als guter alter cookies. Wir möchten, dass das JWT zwischen den Neustarts des Browsers beständig bleibt. Verwenden wir also Local Storage, nicht Session Storage...

Jetzt kann der Benutzer seinen Browser neu starten und er wird weiterhin auf example1.com authentifiziert, solange das JWT-Token nicht abgelaufen ist!

Auch wenn example1.com eine Ajax-Anfrage an eine andere unserer Domänen senden muss, kann ich verstehen, dass die Konfiguration von CORS dies zulässt. Unser Hauptanwendungsfall sind jedoch keine domänenübergreifenden Anfragen, sondern eine Single Sign-On-Lösung!

Daher die Hauptfrage:

Wie sollte nun der Ablauf aussehen, wenn der Benutzer zu example2.com wechselt und er mit dem JWT-Token authentifiziert werden soll, über das er bereits verfügt? Local Storage scheint keinen domänenübergreifenden Zugriff zuzulassen, daher kann der Browser derzeit das JWT-Token nicht lesen, um Anforderungen an example2.com!

Sollte :

  • Der Benutzer wird erneut zum Authentifizierungsserver umgeleitet? Wenn sich der Benutzer für example1.com authentifiziert hat, hat der Authentifizierungsserver möglicherweise ein Cookie für den Benutzer festgelegt, sodass diese neue Authentifizierungsanforderung für example2.com könnte dieses Cookie verwenden, um festzustellen, ob der Benutzer bereits authentifiziert ist, und ihn sofort mit demselben JWT-Token zurück zu example2.com umleiten?
  • Oder kann der Browser auf example2.com auf das JWT-Token zugreifen, ohne erneut zum Authentifizierungsserver gehen zu müssen? Ich sehe, es gibt Cross-Storage-Lösungen , aber sind diese weit verbreitet? Sind sie die vorgeschlagene Lösung für eine domänenübergreifende SSO-Umgebung?

Wir wollen nichts Besonderes, wir würden uns über die meistgenutzte Lösung freuen!

93
electrotype

Der Benutzer sollte erneut zum Authentifizierungsserver umgeleitet werden und ein neues Token (JWT) erhalten, das speziell für example2.com bestimmt ist. So funktioniert OpenID Connect und jedes andere domänenübergreifende SSO-Protokoll.

23
Hans Z.

Das Umleiten von Benutzern zum zentralen Authentifizierungsdienst, wenn der Benutzer nicht angemeldet ist, um Anmeldeinformationen anzufordern und ein neues Authentifizierungstoken auszustellen, ist das gängige Szenario in Single Sign On-Systemen, die bekannte Protokolle wie oauth2 oder OpenIdConnect verwenden

Wenn dieses Schema jedoch für domänenübergreifende Verbindungen verwendet wird, besteht der Hauptnachteil darin, dass der Benutzer jedes Mal authentifiziert wird, wenn er aufgrund derselben Ursprungsrichtlinie zu einer anderen Domäne navigiert: Das Sitzungstoken kann nicht für mehrere freigegeben werden Domänen, sodass der SSO den Benutzer als nicht authentifiziert behandelt.

example2.com Kann nicht auf Daten von example1.com Zugreifen, es gibt jedoch eine Technik, mit der Daten domänenübergreifend mit dem Browser localStorage/cookies und einem Iframe, der auf eine Zwischendomäne verweist, ausgetauscht werden können sso.example.com

  1. Um den Benutzer in example1.com Zu authentifizieren, leiten Sie ihn zum Authentifizierungsserver in sso.example.com Um, stellen Sie nach der Authentifizierung eine JWT aus und speichern Sie diese im localStorage dieser Domain. Danach leiten Sie den Benutzer zur Origin-Domain example1.com um

  2. Erstellen Sie einen iframe in example2.com, Der auf sso.example.com Zeigt. Der iframe in sso.example.com liest das JWT-Token und sendet eine Nachricht an die übergeordnete Seite

  3. Die übergeordnete Seite empfängt die Nachricht und ruft das angehängte Token ab, wobei der SSO-Ablauf fortgesetzt wird

Es gibt kein Problem mit der Same-Origin-Richtlinie, da sso.example.com Zugriff auf seinen localStorage hat und die Kommunikation zwischen iframe und der übergeordneten Seite zulässig ist, wenn Origin und Destination sich gegenseitig erkennen (siehe http: // blog .teamtreehouse.com/domänenübergreifende Nachrichtenübermittlung mit Postnachrichten )

Um die Entwicklung zu vereinfachen, haben wir kürzlich ein domänenübergreifendes SSO mit JWT unter https://github.com/Aralink/ssojwt veröffentlicht

Diese Methode ist perfekt mit SSO-Flows kompatibel. Dies ist nur eine Möglichkeit, das Authentifizierungstoken ohne Umleitungen freizugeben und unnötige Anmeldungen zu vermeiden, wenn die Domänen zusammengeschlossen sind

22
pedrofb

Ich bin nicht sicher, ob dies Ihre Frage beantwortet, aber wenn Ihr Hauptziel Single Sign-On ist, würde ein einfaches Reverse Proxy Ihr Problem lösen (zumindest das domänenübergreifende Speichern).

Also example1.com example2.com

würde sowas werden

example.com/example1

example.com/example2

(Und von der Benutzerseite ist dies normalerweise sauberer)

Wenn dies keine Option ist, müssen Sie möglicherweise festlegen, dass ein Benutzer bei der Authentifizierung in einer Domäne AJAX/versteckte Iframes verwendet, um eine Authentifizierung auch für die anderen Domänen zu erstellen ).

und wenn DAS keine Option ist, müssen Sie möglicherweise auf Benutzername + PIN zurückgreifen, da die Browser hinsichtlich der domänenübergreifenden Interaktion immer strenger werden.

2
Tezra