---
title: "Was ist Single Sign-on Authentication, und wie funktioniert sie?"
description: "In diesem Beitrag erfahren Sie mehr über Single Sign-on Authentication und wie Sie sie für Ihre Web-Apps verwenden können."
authors:
- name: "Sebastian Peyrott"
url: "https://auth0.com/blog/authors/sebastian-peyrott/"
date: "Mar 5, 2019"
category: "Identity & Security,Identity,SSO"
tags: ["single-sign-on", "sso", "federated-identity", "saml", "login", "credentials", "post-series"]
url: "https://auth0.com/blog/de-what-is-and-how-does-single-sign-on-work/"
---
# Was ist Single Sign-on Authentication, und wie funktioniert sie?
Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: Total Economic Impact of Auth0.
[Single Sign-on (SSO)](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog) 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](https://auth0.com/docs/sso/single-sign-on) und sehen Sie sich [die Beispiele](https://github.com/auth0/auth0-sso-sample) 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.
## 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](https://auth0.com/learn/how-to-implement-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.
[Möchten Sie mehr über Single Sign-on erfahren? Holen Sie sich hier den Leitfaden zu SSO (74-seitiges kostenloses eBook)](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)