Single Sign-on (SSO) Authentication ist mehr denn je erforderlich. Heutzutage verlangt fast jede Website eine Authentifizierung, um auf Funktionen und Inhalte zuzugreifen. Mit der steigenden Anzahl von Websites und Services hat sich ein zentrales Loginsystem zu einer Notwendigkeit entwickelt. In diesem zweiteiligen Beitrag wird untersucht, wie SSO Authentication für das Web implementiert wird. Außerdem stellen wir ein Arbeitsbeispiel mit OpenID Connect (in Teil 2) bereit. Lesen Sie weiter!
Föderiertes Identitätsglossar
Das Konzept einer zentralisierten oder verknüpften elektronischen Identität wird als föderierte Identität bezeichnet. Föderierte Identitätssysteme kümmern sich um mehrere Belange:
- Authentifizierung
- Autorisierung
- Austausch von Benutzerattributen
- Benutzerverwaltung
Der Authentifizierungsaspekt umfasst die Validierung von Benutzeranmeldedaten und die Feststellung der Identität des Benutzers. Die Autorisierung bezieht sich auf Zugriffsbeschränkungen (z. B., ist der Benutzer berechtigt, auf die Ressource X zuzugreifen?). Beim Attributaustausch geht es um die gemeinsame Nutzung von Daten über verschiedene Benutzerverwaltungssysteme hinweg. Beispielsweise können Felder wie "real name" in mehreren Systemen vorhanden sein. Ein föderiertes Identitätssystem verhindert die Datenduplizierung durch Verknüpfung der zugehörigen Attribute. Schließlich steht die Benutzerverwaltung im Zusammenhang mit der Administration von Benutzerkonten (Erstellung, Löschung, Aktualisierung). Ein föderiertes Identitätssystem bietet in der Regel die Mittel für Administratoren (oder Benutzer), um Konten über Domains oder Subsysteme hinweg zu verwalten.
SSO steht in engem Zusammenhang mit dem Authentifizierungsteil eines föderierten Identitätssystems. Es geht allein darum, die Identität des Benutzers zu bestimmen und diese Informationen dann mit jedem Subsystem zu teilen, das die Daten benötigt. Im Folgenden werden wir uns auf diesen wichtigen Aspekt des föderierten Identitätssystems konzentrieren.
Single Sign-on (SSO) Authentication
Früher oder später stoßen Webentwickler-Teams auf ein Problem: Sie haben eine Applikation bei Domain X entwickelt und möchten nun, dass bei der neuen Bereitstellung in Domain Y dieselben Logindaten wie in der anderen Domain verwendet werden. Eigentlich möchten Sie sogar noch mehr: Benutzer, die bereits bei Domain X eingeloggt sind, sollen gleichzeitig bei Domain Y eingeloggt sein. Darum geht es bei SSO.
Die offensichtliche Lösung für dieses Problem besteht darin, Sitzungsinformationen über verschiedene Domains hinweg zu teilen. Aus Sicherheitsgründen erzwingen Browser jedoch eine Richtlinie, die als Same-Origin-Policy bekannt ist. Diese Richtlinie schreibt vor, dass auf Cookies (und andere lokal gespeicherte Daten) nur vom Ersteller (d. h. die Domain, die ursprünglich die zu speichernden Daten angefordert hat) aufgerufen werden können. Mit anderen Worten: Domain X kann nicht auf Cookies von Domain Y oder umgekehrt zugreifen. Dieses Problem lösen SSO-Ansätze auf die eine oder andere Weise: sie teilen Sitzungsinformationen über verschiedene Domains hinweg.
Verschiedene SSO-Protokolle teilen Sitzungsinformationen auf verschiedene Weise, aber das wesentliche Konzept ist dasselbe: Es gibt eine zentrale Domain, über die die Authentifizierung durchgeführt wird. Diese Sitzung wird dann auf verschiedene Arten mit anderen Domains geteilt. Beispielsweise kann die zentrale Domain ein signiertes JSON-Webtoken generieren (das mit JWE verschlüsselt werden kann). Dieses Token kann dann an den Client übergeben und von der Authentifizierungsdomain sowie anderen Domains verwendet werden. Das Token kann durch eine Umleitung an die ursprüngliche Domain übergeben werden und enthält alle Informationen zur Identifizierung des Benutzers für die Domain, die eine Authentifizierung erfordert. Da das Token signiert ist, kann es in keiner Weise vom Client geändert werden.
Wenn der Benutzer eine Domain aufruft, die eine Authentifizierung erfordert, wird er an die Authentifizierungsdomain umgeleitet. Da der Benutzer bereits bei dieser Domain eingeloggt ist, kann er mit dem erforderlichen Authentifizierungstoken sofort an die ursprüngliche Domain umgeleitet werden.
Verschiedene Protokolle
Wenn Sie sich online über SSO informiert haben, werden Sie wahrscheinlich festgestellt haben, dass es viele verschiedene Implementierungen gibt: OpenID Connect, Facebook Connect, SAML, Microsoft Account (früher als Passport bekannt) usw. Unser Rat ist es, sich für die zu entscheiden, die am besten zu Ihren Entwicklungen passt. Beispielsweise ist SAML in der Entwicklung von Unternehmen stark verwurzelt, sodass diese Wahl in manchen Fällen durchaus sinnvoll ist. Wenn Sie der Meinung sind, dass Sie Ihre Entwicklung mit mehr als einer Alternative integrieren müssen, sollten Sie nicht verzweifeln: Es gibt Frameworks, die Interoperabilität zwischen verschiedenen SSO-Lösungen ermöglichen. Dies ist eine der Sachen, die wir bei Auth0 tun.
Nebenbemerkung: SSO Authentication mit Auth0
Wenn Sie bereits Auth0 in Ihren Entwicklungen verwenden, wissen Sie, wie einfach SSO sein kann. Wenn dies nicht der Fall ist, lesen Sie die Dokumente über Single Sign-on und sehen Sie sich die Beispiele an. Unsere SSO-Lösung fungiert als Brücke zwischen verschiedenen SSO-Frameworks. Unabhängig davon, welche Apps Sie verwenden, es war noch nie so einfach, SSO in diese zu integrieren. Wir nehmen Ihnen die harte Arbeit ab.
“Unsere SSO-Lösung fungiert als Brücke zwischen verschiedenen SSO-Frameworks.”
Tweet This
Fazit
Die SSO-Authentifizierung hat Bestand. Dezentralisierte Systeme werden immer häufiger, und die Authentifizierung ist ein wesentlicher Bestandteil davon. SSO löst ein großes Problem: die Verwaltung einer wachsenden Anzahl von Benutzern über ein ganzes Ökosystem von Apps und Services hinweg. Frameworks wie OpenID Connect und Services wie der von uns bei Auth0 bereitgestellte Service, vereinfachen die Integration von Single Sign-on in Ihre neuen oder vorhandenen Applikationen. Wenn Sie die Authentifizierung für eine neue App oder einen neuen Service implementieren, erwägen Sie die Integration von SSO von Anfang an.
About the author
Sebastian Peyrott
Senior Engineer