Was ist Single Sign-On (SSO)?

Was ist Single Sign-On (SSO)?

Single Sign-On (SSO) bedeutet, dass sich eine Person einmal anmeldet und mehrere verbundene Anwendungen nutzen kann, ohne sich erneut einzuloggen. Ein Identity Provider (IdP) wie Okta, Microsoft Entra ID, Google Workspace oder Auth0 prüft den Nutzer. Jede Anwendung, der Service Provider (SP), vertraut der signierten Bestätigung des IdP, statt ein eigenes Passwort zu verlangen. In Unternehmen ist SSO verbreitet, weil es viele einzelne Passwörter durch einen verwalteten Login ersetzt.

So funktioniert SSO

Der Ablauf ist bei allen Protokollen ähnlich:

1. Der Nutzer klickt in der Anwendung auf "Anmelden".
2. Die Anwendung leitet den Browser mit einer Authentifizierungsanfrage zum IdP um.
3. Der IdP authentifiziert den Nutzer: Passwort, MFA, Richtlinien zu Gerät oder Standort.
4. Der IdP stellt ein signiertes Token aus (Assertion oder ID-Token), das sagt, wer der Nutzer ist, oft mit E-Mail, Name und Gruppen.
5. Der Browser kehrt mit dem Token zur Anwendung zurück.
6. Die Anwendung prüft die Signatur mit dem öffentlichen Schlüssel des IdP und startet eine eigene Sitzung.

Für den Nutzer sind das ein paar Weiterleitungen. Besteht bereits eine IdP-Sitzung, sieht er womöglich gar keine Anmeldeseite.

Die wichtigsten SSO-Protokolle: SAML, OIDC und OAuth

SAML 2.0

Ein XML-basierter Standard, den OASIS im März 2005 verabschiedet hat. Die Assertions werden mit X.509-Zertifikaten signiert. SAML ist ausführlich und schwerer zu debuggen als neuere Verfahren, aber in Unternehmenssoftware weit verbreitet. Details finden Sie unter Was ist SAML.

OpenID Connect (OIDC)

Eine schlanke Identitätsschicht auf OAuth 2.0. Die Anwendung erhält ein ID-Token, ein signiertes JSON Web Token mit Identitätsangaben. OIDC basiert auf JSON und ist leichter umzusetzen, deshalb starten viele neuere Produkte damit.

OAuth 2.0

OAuth ist ein Autorisierungs-Framework: Es beantwortet "Darf diese App auf diese Daten zugreifen?", nicht "Wer ist dieser Nutzer?". Wegen ähnlicher Weiterleitungen wird es oft mit SSO verwechselt. OIDC ergänzt die standardisierte Identitätsschicht, die den Ablauf zu echter Authentifizierung macht. Die ausgestellten Access Tokens werden meist als Bearer Token gesendet.

SP-initiierter vs. IdP-initiierter Login

• SP-initiiert: Der Nutzer öffnet zuerst die Anwendung, wird zum IdP umgeleitet und kehrt zurück. Das ist der häufigste Ablauf.
• IdP-initiiert: Der Nutzer startet im App-Launcher des IdP und klickt die Kachel der Anwendung; der IdP sendet eine Assertion, die die Anwendung nie angefordert hat. Das ist bequem, verlangt aber besondere Sorgfalt, weil die Anwendung eine unaufgeforderte Assertion akzeptieren muss.

Warum SSO die Sicherheit verbessern kann

• Zentrale MFA. Starke Authentifizierung wird einmal am IdP erzwungen statt in jeder App.
• Eine Stelle zum Entziehen von Zugriff. Wird das IdP-Konto eines ausgeschiedenen Mitarbeiters gesperrt, verliert er den Zugriff auf alle verbundenen Apps.
• Weniger Passwort-Wiederverwendung. Ein verwalteter Login ersetzt viele einzelne Passwörter.
• Ein Audit-Trail. Anmeldungen und Fehlversuche stehen in den Logs des IdP.

Der Preis ist die Bündelung: Der IdP wird zur kritischen Abhängigkeit und zum attraktiven Ziel, also mit MFA schützen und für kritische Apps einen Notfallzugang außerhalb von SSO behalten. SSO regelt zudem nicht, was ein Nutzer darf; das ist Autorisierung über Rollen in der Anwendung (siehe rollenbasierte Zugriffskontrolle und Identity and Access Management).

Häufige SSO-Fehler

• Zeitabweichung. SAML-Assertions haben die Zeitstempel NotBefore und NotOnOrAfter; weichen die Uhren von IdP und SP zu stark ab, scheitert der Login. Beide per NTP synchronisieren.
• Abgelaufene Signaturzertifikate. SAML-Zertifikate laufen ab. Datum im Blick behalten und vorher erneuern.
• Falsche Gruppenzuordnung. Werden IdP-Gruppen nicht auf Rollen der Anwendung abgebildet, haben Nutzer nach der Migration falsche Rechte.
• Kein Provisionierungskonzept. Ohne Just-in-Time-Provisionierung oder SCIM legt ein Admin jeden Nutzer von Hand an, und Ausgeschiedene behalten verwaiste Konten.
• Single Logout als selbstverständlich annehmen. Das Abmelden in einer App beendet oft weder die IdP-Sitzung noch die anderer Apps.
• Unterschiedliche Sitzungsdauern. Eine lange IdP-Sitzung neben einer kurzen App-Sitzung führt zu ständigen Neuanmeldungen.

SSO vs. Föderation vs. OAuth

• SSO ist das Nutzererlebnis: ein Login, viele Apps. Wie es gebaut ist, sagt der Begriff nicht.
• Föderierte Identität ist die Vertrauensbeziehung, durch die IdP und SP in verschiedenen Organisationen die Identitäten des anderen akzeptieren.
• OAuth 2.0 delegiert den Zugriff auf Daten; allein stellt es nicht fest, wer der Nutzer ist.
• OIDC ergänzt OAuth um ein ID-Token mit Identitätsangaben.

Häufige Fragen zu Single Sign-On (SSO)

Was ist der Unterschied zwischen SSO und einem Passwortmanager?

Ein Passwortmanager speichert für jede App ein eigenes Passwort und füllt es aus. SSO schafft das Passwort pro App ab: Die App vertraut stattdessen der Prüfung des IdP. SSO braucht Unterstützung in jeder App, ein Passwortmanager funktioniert mit jedem Anmeldeformular.

SAML oder OIDC?

Für neue Integrationen ist OIDC meist einfacher zu bauen und zu debuggen. Viele Unternehmenskunden und Identity Provider verlangen weiterhin SAML, weshalb Produkte für größere Organisationen oft beides unterstützen.

Was ist die SSO-Steuer?

Gemeint ist, dass Anbieter für einen Tarif mit SSO deutlich mehr verlangen. Die Seite sso.tax listet, welche Anbieter das tun.

Was ist SCIM und wie hängt es mit SSO zusammen?

SCIM (System for Cross-domain Identity Management) automatisiert das Anlegen, Ändern und Entfernen von Benutzerkonten zwischen IdP und Anwendungen. SSO regelt die Anmeldung, SCIM den Lebenszyklus der Konten.

Was passiert, wenn der Identity Provider ausfällt?

Nutzer können sich bei davon abhängigen Apps nicht anmelden, sofern sie keine gültige Sitzung haben. Für kritische Apps sollte mindestens ein lokales Notfall-Adminkonto ohne SSO bestehen.

Lasttest einer App hinter SSO

LoadFocus selbst bietet kein SAML- oder OIDC-Single-Sign-On: Die Anmeldung erfolgt mit E-Mail und Passwort oder mit Google, und Teammitglieder werden mit Vollzugriff oder nur lesend eingeladen. SSO spielt für die getestete App eine Rolle. Ein echter SSO-Login läuft über Browserseiten des Identity Providers, die ein Lasttest nicht belasten sollte. Üblich ist, einmal ein Token von einem Testclient zu holen, etwa mit dem OAuth-Client-Credentials-Flow in einem Test-Tenant, und es als Authorization-Header zu senden. Siehe OAuth-2.0-Lasttests und OAuth-geschützte Apps mit JMeter testen; die Tests laufen mit LoadFocus Load Testing, auch mit JMeter-Skripten.