Wie funktioniert Single Sign-On und worin unterscheiden sich SAML und OIDC?
Kurzantwort
SSO zentralisiert die Authentifizierung bei einem Identity Provider (IdP). Besucht ein Benutzer einen Service Provider (die App), leitet die App zum IdP weiter; der Benutzer meldet sich einmal an, und der IdP gibt eine signierte Assertion oder ein Token zurück, das seine Identität bürgt. SAML trägt dies als signierte XML-Assertion; OIDC trägt es als signiertes JSON-ID-Token auf OAuth 2.0. Die App vertraut der Signatur des IdP, statt Passwörter selbst zu handhaben.
SSO-Fragen prüfen, ob du föderiertes Vertrauen verstehst: viele Anwendungen, die den Akt der Authentifizierung an einen einzigen Identity Provider auslagern. Die SAML-vs-OIDC-Unterscheidung richtig zu treffen, zeigt, dass du tatsächlich damit gearbeitet hast.
Das Kernmodell
Beim SSO gibt es zwei Rollen: den Identity Provider (IdP), der Benutzer authentifiziert, und den Service Provider (SP) – die Anwendung –, der sich auf ihn verlässt. Erreicht ein Benutzer die App, leitet sie ihn zum IdP weiter. Ist er dort bereits angemeldet, erscheint keine Aufforderung; andernfalls authentifiziert er sich einmal. Der IdP schickt den Browser dann zur App zurück und trägt eine kryptografisch signierte Aussage, die besagt: „Das ist die Identität des Benutzers." Die App verifiziert die Signatur des IdP und erstellt eine lokale Sitzung. Der Benutzer gibt seine Anmeldedaten einmal ein und erreicht jede föderierte App.
Der große Vorteil ist die Zentralisierung: ein Ort, um MFA, Passwortrichtlinie, bedingten Zugriff und Deprovisionierung durchzusetzen. Deaktiviere das Konto beim IdP, und der Zugriff stirbt überall auf einen Schlag.
SAML vs OIDC
- SAML 2.0 ist der ältere Unternehmensstandard. Der IdP stellt eine signierte XML-Assertion aus, typischerweise über einen Browser-POST geliefert. Es ist ausgereift und im B2B-/Unternehmensumfeld allgegenwärtig, doch XML ist schwerfällig und für Mobile und SPAs umständlich.
- OIDC (OpenID Connect) ist eine Identitätsschicht auf OAuth 2.0. Der IdP stellt ein JSON-ID-Token (ein JWT) neben den OAuth-Tokens aus. Es ist leichtgewichtig, JSON-/REST-freundlich und der Standard für moderne Web-, Mobil- und API-getriebene Apps.
Beide verlassen sich darauf, dass der SP die Signatur des IdP verifiziert, um der Assertion zu vertrauen – diese Signatur ist die gesamte Grundlage des Vertrauens.
Das Risiko
SSO konzentriert das Risiko: Der IdP wird zum Single Point of Failure und zu einem verlockenden Ziel. Wird er kompromittiert (oder lässt sich eine SAML-Assertion durch einen Parsing-Bug fälschen), erhält der Angreifer alles. Deshalb verlangen IdPs die stärkste, phishing-resistente MFA.
Worauf Interviewer achten
Das IdP/SP-Modell aus Weiterleitung und signierter Assertion, den Vorteil ein-Login-viele-Apps, SAML (signiertes XML) vs OIDC (JWT auf OAuth), die Signaturprüfung als Wurzel des Vertrauens und das Bewusstsein für den konzentrierten Schadensradius.
Wahrscheinliche Anschlussfragen
- Warum wird OIDC für moderne und mobile Apps oft SAML vorgezogen?
- Wie groß ist der Schadensradius, wenn der IdP kompromittiert wird, und wie reduziert man ihn?
- Wie verifiziert die App, dass eine SAML-Assertion oder ein OIDC-ID-Token echt ist?