Was ist Single Sign-On (SSO)?

Single Sign-On ist eine Authentifizierungsmethode, bei der eine Anmeldung bei einem Identity Provider viele eigenständige Anwendungen öffnet. Die Besetzung besteht aus zwei Rollen: Der Identity Provider (IdP) authentifiziert Nutzer und bürgt für sie; jeder Service Provider (SP) – die Apps, die Sie eigentlich wollen – vertraut dieser Bürgschaft, statt eine eigene Anmeldung zu betreiben. Eine pedantische Unterscheidung lohnt sich: Apps, die dasselbe Verzeichnis nutzen, aber jede für sich das Passwort abfragen, sind Same Sign-On; echtes SSO heißt, dass Sie genau einmal gefragt werden.

Das Wichtigste in Kürze

Der Redirect-Tanz, Schritt für Schritt

Warum überhaupt Umleitungen? Wegen der Same-Origin-Policy des Browsers: app.example.com kann kein Anmelde-Cookie für idp.example.org lesen, also muss die Identität als signierte Nachricht durch den Browser reisen statt als geteiltes Cookie – und genau das tut der Ablauf:

1  Nutzer öffnet app.example.com – keine Session
2  SP leitet mit einer Authentifizierungsanfrage zum IdP um
3  Nutzer authentifiziert sich BEIM IDP (Passwort + MFA) – oder er
   hat schon eine IdP-Session, dann entfällt der Schritt stillschweigend
4  IdP stellt signierte Assertion (SAML-XML) bzw. ID Token (OIDC-JWT) aus
5  Browser liefert sie an die Callback-URL des SP
6  SP validiert: Signatur · Issuer · Audience · Ablauf · Replay
7  SP startet seine eigene lokale Session – der Nutzer ist drin
8  Nächste App: Schritte 1–2, dann direkt vom stillen Pfad aus 3 zu 7

So sieht die Seite des Service Providers aus, wenn ein Backend sie kapselt:

// JavaScript / Node.js — Back4app JS SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
const user = await Parse.User.logInWith('keycloak', {
  authData: {
    id: subClaim,              // the IdP's stable subject ID
    access_token: accessToken, // verified server-side against the IdP
  },
});
// One IdP login now serves every app that trusts the same issuer.

// Flutter / Dart — Back4app Flutter SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
final user = ParseUser.forQuery();
final response = await user.loginWith('keycloak', {
  'id': subClaim,              // the IdP's stable subject ID
  'access_token': accessToken, // verified server-side against the IdP
});
// One IdP login now serves every app that trusts the same issuer.

// iOS / Swift — Back4app Swift SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
let user = try await User.loginWith(
    "keycloak",
    authData: [
        "id": subClaim,              // the IdP's stable subject ID
        "access_token": accessToken  // verified server-side against the IdP
    ]
)
// One IdP login now serves every app that trusts the same issuer.

// Android / Kotlin — Back4app Android SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
val authData = mapOf(
    "id" to subClaim,              // the IdP's stable subject ID
    "access_token" to accessToken  // verified server-side against the IdP
)
ParseUser.logInWithInBackground("keycloak", authData).continueWith { task ->
    val user = task.result
    // One IdP login now serves every app that trusts the same issuer.
}

SP-initiiert vs. IdP-initiiert

Die meisten Erklärtexte beschreiben nur den ersten Fall und benennen den zweiten nie – doch Unternehmens-IdPs lieben Dashboard-Kacheln, also begegnen SPs beiden. Die technische SAML-Übersicht spezifiziert beide Profile; die praktische Regel steht in der letzten Zeile der Tabelle.

SAML vs. OIDC

Und das Dreieck, das die Abkürzungen ein für alle Mal entwirrt: SAML und OIDC erledigen die Authentifizierung für SSO; OAuth 2.0 allein ist Autorisierung – OIDC ist die Identitätsschicht, die es sicher machte, sich über die OAuth-Mechanik anzumelden. Social Login ist dieselbe OIDC-Maschinerie mit einer Consumer-Plattform als IdP und einer einzelnen App als Audience; Unternehmens-SSO wechselt den Hausherrn und weitet die Session auf eine ganze Suite aus.

Die Teile, die niemand erwähnt

Single Logout (SLO) ist die schwere Hälfte. Die Anmeldung läuft auf einen IdP zu; die Abmeldung muss hinaus an jeden SP mit lokaler Session – und die Kette reißt, wenn eine App nicht antwortet, Browser-Beschränkungen für Drittanbieter-Cookies die Front-Channel-Benachrichtigungen brechen und Ihre anderen Geräte gar nichts erreicht. In der Praxis bedeutet “überall abgemeldet” kurze lokale Sessions, die die (beendete) IdP-Session erneut prüfen, und keine verlässliche Rundmeldung. Sessions laufen auf drei Uhren: der globalen Session des IdP, der lokalen Session jeder App und dem Gültigkeitsfenster der Assertion selbst. Sich von einer App abzumelden, während die IdP-Session weiterlebt, bedeutet beim nächsten Besuch den stillen Wiedereintritt – ein Verhalten, das Nutzer als Bug melden und Architekten als das Design erkennen sollten. Und die SSO-Steuer: SaaS-Anbieter sperren SAML- bzw. SSO-Unterstützung routinemäßig hinter Enterprise-Stufen zum Vielfachen des Grundpreises – eine Marktrealität, die ins Budget gehört, denn die Anforderung des Sicherheitsteams und der Posten im Einkauf treffen gemeinsam ein.

Der Schadensradius, ehrlich betrachtet

SSO konzentriert Risiko mit Absicht – genau das bedeutet “single”. Ein kompromittiertes IdP-Konto öffnet jede angebundene App; ein kompromittierter IdP selbst – einschließlich des Diebstahls seiner Signaturschlüssel für Assertions, das Angriffsmuster der “Golden Assertion” – prägt gültige Identitäten für jeden, überall. Anbieter reden das weich; die ingenieurtechnische Antwort lautet, die Konzentration klug einzusetzen: phishing-resistente MFA beim IdP (die eine Anmeldung ist jetzt Schutz auf Passkey-Niveau wert), Step-up-Authentifizierung für sensible Apps statt einer pauschalen Session, kurze globale Sessions dort, wo viel auf dem Spiel steht, Rotation und Monitoring der Signaturschlüssel sowie lokale Notfallkonten für den Tag, an dem der IdP ausfällt. Der Single Point of Failure verschwindet nie – er wird gepanzert, denn genau einen Punkt zu panzern ist die Ökonomie, die SSO versprochen hat.

Die Anbindung als Service Provider

Was “wir unterstützen SSO” ein App-Team tatsächlich kostet, in einer Liste: Callback- bzw. ACS-URL beim IdP registrieren und Metadaten austauschen (Issuer, Zertifikate); bei jeder Assertion alles validieren – Signatur, Issuer, Audience, Ablaufzeit und Replay-Bindung; die Claims des IdP auf Ihr Nutzermodell abbilden, verankert an der stabilen Subject-ID, nie an der E-Mail allein; just in time provisionieren (die erste SSO-Anmeldung legt den lokalen Nutzer an); IdP-initiierte Ankünfte bewusst behandeln; und die Erwartungen an die Abmeldung gegen die Realität der drei Uhren testen. Es ist ein ausgetretener Pfad – deshalb existieren Open-Source-IdPs wie Keycloak für die andere Seite des Handschlags –, aber jeder übersprungene Punkt ist ein Sicherheitsbefund mit Datum.

Typische Anwendungsfälle

• App-Suiten für Mitarbeitende – der kanonische Fall: eine Anmeldung am Morgen, danach jedes interne und jedes SaaS-Werkzeug.
• B2B-SaaS im Aufstieg ins Enterprise-Segment – “unterstützt SSO” als Häkchen, das den Abschluss überhaupt erst möglich macht.
• Bildung und Gesundheitswesen – föderierter Zugriff über Einrichtungen hinweg, wo die Wurzeln von SAML am tiefsten reichen.
• Zentrale MFA und Offboarding – eine Stelle, um Faktoren zu erzwingen; ein Schalter, der den Zugriff einer ausgeschiedenen Person überall beendet.
• Produkte aus mehreren Apps – Ihre eigene Suite teilt sich über einen eigenen IdP eine Anmeldung, im Consumer-Stil.

Sollten Sie SSO ergänzen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Verfügbarkeit konzentriert sich mit der Identität. Die Ausfallzeit des IdP ist der Anmeldeausfall aller; Redundanz und Notfallwege sind Teil des Features, keine Zutaten obendrauf.
• Die Abmeldung ist schwächer als die Anmeldung. Der Fan-out von SLO scheitert konstruktionsbedingt teilweise; kurze lokale Sessions liefern die echte Garantie, keine Abmelde-Rundrufe.
• Der lange Schwanz bleibt passwortgeschützt. Apps ohne SSO-Unterstützung behalten ihre eigenen Zugangsdaten – Passwortmanager bleiben die Aufräumschicht.
• Die Schichtung der Sessions verwirrt Nutzer. Stille Neuanmeldung und Tickets im Stil von “ich habe mich abgemeldet, war es aber nicht” sind die UX-Rechnung für das Drei-Uhren-Design; Dokumentation und vorhersehbare Timeouts tilgen sie.
• Die Qualität der Anbindung schwankt je SP. Die Sicherheitsobergrenze von SSO setzt die nachlässigste Assertion-Validierung unter Ihren angebundenen Apps – die Checkliste oben gilt pro App, auf Dauer.

SSO mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Eine App tritt hier als Service Provider in eine SSO-Landschaft ein, und zwar über denselben Adapter-Mechanismus, der auch Social Login trägt: Back4app liefert Auth-Adapter für Keycloak, LDAP und generische OAuth2- bzw. OIDC-Issuer, sodass der Ablauf aus den Code-Tabs – der IdP authentifiziert, die App erhält Tokens, logInWith prüft sie serverseitig beim Issuer – Unternehmens-SSO auf Konfiguration plus einen Redirect-Handler reduziert. Identitäten verankern sich am stabilen Subject des IdP in authData pro Anbieter, die erste Anmeldung provisioniert den Nutzer just in time, linkWith hängt weitere Methoden für den Notfallweg an, und die Session, die Ihre App ausstellt, bleibt eine widerrufbare Parse-Session – damit endet die Schichtung der drei Uhren auf Ihrer Seite mit einer Uhr, die Sie vollständig kontrollieren.