Single Sign-on anbinden: So funktioniert es, so gehen Sie vor

Single Sign-on (SSO) ist kein Produkt, das Sie installieren. Es ist eine Anbindung zwischen einem zentralen Identitätsanbieter und jeder Anwendung, die Ihr Team nutzt. Der Identitätsanbieter prüft, wer die Person ist, und jede angebundene Anwendung vertraut diesem Entscheid. Damit das gut gelingt, zählen vier Dinge: das passende Protokoll (SAML oder OpenID Connect), die Einigung darüber, welche Identitätsdaten jede Anwendung erhält, das Anlegen und Löschen von Konten sowie Tests, bevor Sie SSO verbindlich machen. Wir bauen und verbinden Geschäftssysteme im Alltag, und dieser Leitfaden führt Sie durch den ganzen Weg.

Das Wichtigste in Kürze

• SSO ist eine Anbindung: Ein Identitätsanbieter prüft die Person, und jede Anwendung (der Dienstanbieter) verlässt sich auf dieses Urteil.
• Nutzen Sie SAML 2.0 für klassische Unternehmensanwendungen im Web und OpenID Connect (OIDC) für moderne Webanwendungen, mobile Apps und APIs.
• SSO regelt nur die Anmeldung. Ergänzen Sie SCIM, wenn Konten automatisch angelegt und deaktiviert werden sollen, sobald jemand dazukommt oder geht.
• Planen Sie der Reihe nach: Anwendungen erfassen, Attribute und Rollen festlegen, Pilot mit risikoarmen Anwendungen, testen, dann verbindlich machen und überwachen.
• In der Schweiz bleiben Sie für Rechtsgrundlage, Auftragsbearbeiter, Bekanntgabe ins Ausland, Protokollierung und Löschung verantwortlich, auch wenn ein Cloud-Anbieter die Anmeldung betreibt.

Ist Single Sign-on eine Anbindung?

Ja. Microsoft defines SSO als einmalige Anmeldung mit einem einzigen Satz von Zugangsdaten, danach erreichen Sie die Ihnen zugewiesenen Anwendungen ohne erneute Anmeldung. Hinter diesem Erlebnis prüft ein zentraler Identitätsanbieter die Person und bestätigt jeder Anwendung ihre Identität.

Deshalb suchen viele nach dem Begriff «Single Sign-on Integration». SSO einzuschalten heisst, zwei Seiten miteinander zu verbinden:

• Der Identitätsanbieter (IdP): die zentrale Instanz, zum Beispiel Microsoft Entra ID oder Okta.
• Der Dienstanbieter (SP): Ihr CRM, Ihr ERP, Ihr Kundenportal, Ihre internen Werkzeuge. Okta describes den IdP als zentrale Instanz für die Authentifizierung und die Anwendungen als Dienstanbieter, die sich auf dessen föderierten Identitätsentscheid stützen.

Die verwandte Frage «API oder SSO?» hat eine kurze Antwort. Über eine API ruft ein System ein anderes auf, um Daten auszutauschen oder Aktionen auszulösen. Mit SSO weist eine Person einmal nach, wer sie ist. Oft treffen beide aufeinander: OIDC bedient zum Beispiel auch APIs, die sowohl Authentifizierung als auch Autorisierung brauchen.

So läuft die Anmeldung ab

Beim üblichen Ablauf, der von der Anwendung ausgeht, ist die Abfolge einfach:

1. Die Person öffnet eine Anwendung.
2. Die Anwendung leitet sie zum Identitätsanbieter weiter.
3. Der IdP prüft die geschäftlichen Zugangsdaten und bestätigt die Identität.
4. Die Anwendung gewährt Zugriff.

Microsoft defines SSO. Unterstützt werden ebenso identity-provider-initiated flows für SAML-Anwendungen, bei denen die Person in einem Portal startet (Microsoft nennt es My Apps) und auf eine Kachel klickt. Abläufe, die von der Anwendung ausgehen, funktionieren sowohl mit SAML als auch mit OIDC.

Wer den Ablauf einmal vor Augen hat, erkennt auch die Bruchstellen: Weiterleitungsadressen, die nicht übereinstimmen, abgelaufene Zertifikate und Attribute, die leer ankommen oder anders heissen, als die Anwendung erwartet.

SAML, OpenID Connect und OAuth: Was Sie wann einsetzen

Das Protokoll bestimmt, wie Identitätsangaben verpackt und an Ihre Anwendung geliefert werden. Microsoft defines SSO ist SAML 2.0 ein XML-basierter Standard, der in Unternehmen weit verbreitet ist und sich für klassische Webanwendungen und detaillierte Benutzerattribute eignet. OIDC baut auf OAuth 2.0 auf, nutzt JSON-basierte Token und passt zu modernen Webanwendungen, mobilen Apps und APIs, die sowohl Authentifizierung als auch Autorisierung benötigen.

	SAML 2.0	OpenID Connect
Format	XML-Assertions	JSON-basierte Token (ID-Token)
Typischer Einsatz	Klassische Unternehmensanwendungen im Web, umfangreiche Benutzerattribute	Moderne Webanwendungen, mobile Apps, APIs
Baut auf	Eigenem Standard	OAuth 2.0
Typische Einrichtungsangaben	Entity ID, Reply-URL, Signaturzertifikat oder Metadaten	Issuer, Client-ID, Client Secret, Redirect-URIs

Eine Unterscheidung bringt viele Teams ins Stolpern. OAuth 2.0 is an authorization framework für den delegierten Zugriff auf geschützte Ressourcen. OpenID Connect ergänzt darauf aufbauend eine standardisierte Authentifizierung von Personen und Identitätsangaben. Wenn Sie wissen müssen, wer die Person ist, brauchen Sie OIDC (oder SAML), nicht OAuth allein.

Keines der beiden Protokolle ändert, wer über die Authentifizierung entscheidet. Gemäss identity-provider-initiated flows ändern sie nur, wie die Identität geliefert wird. Wählen Sie also nach dem, was Ihre Anwendung unterstützt und was Sie als Nächstes brauchen: Bietet die Anwendung eines Anbieters nur SAML, nehmen Sie SAML. Bauen Sie ein neues Produkt mit mobiler App, ist OIDC die naheliegende Wahl.

Planen Sie die Anbindung, bevor Sie Einstellungen anfassen

Die meisten gescheiterten Rollouts überspringen die Planung. Drei Dinge gehören zuerst aufs Papier.

Erfassen Sie Ihre Anwendungen

Das US-amerikanische Enterprise SSO Playbook macht eine Übersicht der Anwendungen zum ersten Planungsschritt. Halten Sie je Anwendung fest, welche Protokolle unterstützt werden, welche Benutzergruppen sie nutzen, welche Attribute nötig sind, wie Konten angelegt werden und wie kritisch die Anwendung ist. Die letzte Spalte bestimmt Ihre Reihenfolge beim Rollout.

Einigen Sie sich auf die Identitätsdaten

Die AGOV guidance des Bundes nennt die Punkte zur Interoperabilität, die eine Vertrauenskonfiguration festlegen sollte: Claims und Attribute, stabile Personenkennungen, Rollen- und Gruppenzuordnungen sowie Verfahren zur Signierung oder Verschlüsselung. Am wichtigsten ist eine stabile Kennung. Wenn Anwendungen Personen über die E-Mail-Adresse zuordnen und jemand den Namen ändert, entstehen doppelte oder verwaiste Konten. Legen Sie pro Person eine unveränderliche Kennung fest und verwenden Sie diese überall.

Die Rollenzuordnung verdient gleich viel Sorgfalt. Entscheiden Sie, welche IdP-Gruppe in welcher Anwendung zu welcher Rolle wird, und halten Sie es schriftlich fest. Sonst bedeutet «Admin» im einen System unbemerkt etwas anderes als im nächsten.

Legen Sie die Reihenfolge des Rollouts fest

Dasselbe Playbook empfiehlt zusammen mit weiteren Quellen, die es zusammenfasst, ein stufenweises Vorgehen: Beginnen Sie mit Anwendungen mit geringem Risiko, nutzen Sie die Rückmeldungen aus dem Pilot vor der vollen Freigabe und Enterprise SSO Playbook. Nehmen Sie Ihr internes Wiki oder ein Projektwerkzeug in den Pilot, nicht Ihre Buchhaltung.

Schritt für Schritt: eine Anwendung anbinden

Die Schritte unterscheiden sich je nach Protokoll leicht. Das Muster bleibt dasselbe.

Schritt 1: Die Anwendung im Identitätsanbieter registrieren

Bei einer OIDC-Verbindung entstehen bei der Registrierung ein Issuer, eine Client-ID und ein Client Secret. Ihre Anwendung wird mit Redirect-URIs konfiguriert und muss das ID-Token des Anbieters prüfen. Guard.ch’s setup guide beschreibt diese Felder und Prüfschritte aus der Praxis.

Bei einer SAML-Verbindung braucht die Registrierung in der Regel die Entity ID, die Assertion-Consumer-Service-URL (Reply-URL), ein Signaturzertifikat oder Föderationsmetadaten, die Zuordnung der Claims, die Zuweisung der Personen und ein Testkonto, wie listed in this Entra integration guide.

Wo es schiefgeht: ein abschliessender Schrägstrich in einer Redirect-URI, ein Zertifikat, bei dem die Zeilenumbrüche verloren gingen, oder ein Client Secret, das abläuft, ohne dass jemand für die Erneuerung zuständig ist. Tragen Sie die Ablaufdaten ab dem ersten Tag in einen gemeinsamen Kalender ein.

Schritt 2: Claims und Rollen zuordnen

Senden Sie nur die Attribute, welche die Anwendung braucht: eine stabile Kennung, eine E-Mail-Adresse, den Namen sowie Gruppe oder Rolle. Weniger Attribute bedeuten weniger Personendaten im Umlauf, was auch bei den Schweizer Datenschutzpunkten weiter unten hilft.

Schritt 3: Personen zuweisen

Starten Sie mit einer kleinen, namentlich bekannten Gruppe. Bei SAML-Einrichtungen gehört die Zuweisung der Personen zur Anwendung im IdP zur Registrierung; wird sie vergessen, erhalten eigentlich berechtigte Personen eine verwirrende Meldung «Zugriff verweigert».

Schritt 4: Mit einem echten Konto testen

Dem Testen ist weiter unten ein eigener Abschnitt gewidmet. Machen Sie SSO nicht verbindlich, bevor eine vollständige Anmeldung von Anfang bis Ende funktioniert.

Schritt 5: Verbindlich machen, dann überwachen

Erst nach einem erfolgreichen Pilot verlangen Sie SSO für alle und deaktivieren die Anmeldung per Passwort. Dokumentieren Sie mindestens einen Notfallzugang für Administrator:innen, damit ein falsch konfigurierter IdP nicht die ganze Firma aussperrt.

Provisionierung: SSO entfernt keine Konten

Diesen Teil behandeln die meisten Anleitungen nur oberflächlich. SSO authentifiziert; es verwaltet nicht den Lebenszyklus der Konten. Wie listed in this Entra integration guide festhält, authentifizieren SAML oder OIDC die Person, während SCIM die Konten in den Anwendungen anlegt und wieder entfernt; empfohlen wird beides für den vollständigen Lebenszyklus.

Der Unterschied zeigt sich beim Austritt. SAML just-in-time provisioning legt bei der ersten Anmeldung ein Konto an, kann es aber nicht wieder entfernen. SCIM kann Konten vor der ersten Anmeldung anlegen und beim Austritt deaktivieren. Ist das IdP-Konto einer ehemaligen Mitarbeiterin deaktiviert, das Konto in der Anwendung bleibt aber bestehen, können noch gültige Token oder Sitzungen weiterhin funktionieren.

Wenn Sie SCIM in Ihrer eigenen Anwendung umsetzen, behandeln Sie active=false als sofortigen Entzug des Zugriffs. The SCIM guide notes hält fest, dass Okta üblicherweise ein PATCH sendet, das active auf false setzt, statt ein DELETE. Eine Anwendung, die auf ein DELETE wartet, entzieht den Zugriff somit nie.

Die Anbindung testen und pflegen

Ein guter Testablauf prüft mehr als nur «bin ich reingekommen». Guard.ch’s setup guide führt eine Anmeldung beim Anbieter durch, ohne die Person tatsächlich anzumelden, zeigt die erhaltene Adresse und die Claims an und verlangt nach Änderungen an der Verbindung einen erfolgreichen Test, bevor SSO verbindlich werden kann. Dieses Muster lohnt sich zum Nachahmen: Sehen Sie genau, was der IdP gesendet hat, bevor Sie ihm vertrauen.

Für die Provisionierung empfiehlt Bynder’s support guide, eine echte Testperson zu verwenden, die nötigen Attribute und Berechtigungen zu prüfen und die Protokolle der Provisionierung durchzusehen.

Eine kurze Testliste:

• Eine neue Person meldet sich zum ersten Mal an und landet mit der richtigen Rolle.
• Eine Person in der falschen Gruppe wird abgewiesen.
• Eine deaktivierte Person kann sich nicht mehr anmelden, und ihr Konto in der Anwendung ist deaktiviert.
• Eine Person, die die Abteilung wechselt, erhält die neue Rolle.
• Nach jeder Änderung an der Verbindung (neues Zertifikat, neues Secret) läuft der Test erneut erfolgreich durch, bevor SSO verbindlich gilt.

Die Pflege ist vor allem Kalenderarbeit: Zertifikate und Secrets erneuern, Gruppenzuordnungen bei Umorganisationen prüfen und die Anmeldeprotokolle regelmässig durchsehen.

Sicherheit: Was SSO bündelt

SSO beseitigt den Passwortwildwuchs, bündelt aber das Risiko. Auth0 explains, dass sich das Risiko in Token und Anwendungssitzungen konzentriert. Die Gegenmassnahmen sind konkret: Signaturen, Ablauf, Issuer und Audience der Token prüfen; PKCE, sichere Speicherung der Token, kurzlebige Access Tokens und Rotation der Refresh Tokens einsetzen; Zeitlimits für Sitzungen und eine zusätzliche Authentifizierung bei besonders heiklen Aktionen verlangen.

Die Unterlagen des NIST zur Token-Sicherheit betonen, dass signing keys are the root of trust und dass Assertions und Token eingegrenzt, geprüft und zeitlich befristet sein sollten. In der Praxis heisst das: den Kreis der Personen mit Zugriff auf Signaturschlüssel klein halten und die Schlüssel nach Plan wechseln.

Bei kritischen Diensten ergänzen Sie weitere Schichten, statt sich allein auf die Anmeldung zu verlassen. Eine security analysis by Doyensec argumentiert, Sie sollten nicht davon ausgehen, dass der Identitätsanbieter immer sicher bleibt, und nennt zusätzliche Mehrfaktor-Authentifizierung, Zugriffsanfragen nach dem Prinzip der minimalen Rechte, kurzlebige Zertifikate und fortlaufende Überwachung. Verlangen Sie beim Identitätsanbieter einen zweiten Faktor; ein multi-factor authentication setup guide zeigt, wie diese Schicht für Konten wie E-Mail üblicherweise eingerichtet wird.

Schweizer Datenschutzpunkte

Wenn Ihre Nutzer:innen oder Kund:innen in der Schweiz sind, steht das Anmeldesystem nicht ausserhalb des Datenschutzes. Die AGOV-Hinweise zu AGOV guidance halten fest, dass die Organisation weiterhin für Rechtsgrundlage, Zweck und Verhältnismässigkeit, die Wahl des Cloud- oder SaaS-Anbieters, Zugriffsrechte und Informationssicherheit verantwortlich bleibt. Genannt werden ebenso Auftragsbearbeiter und Unterauftragsbearbeiter, Bekanntgabe ins Ausland, Aufbewahrung und Löschung, Protokollierung, Fortführung und Ausstieg sowie die Information der betroffenen Personen.

Übersetzt in Projektaufgaben:

• Halten Sie fest, welcher Anbieter den Identitätsdienst betreibt und wo die Daten bearbeitet werden.
• Beschränken Sie die Claims an jede Anwendung auf das, was diese Anwendung braucht.
• Legen Sie die Aufbewahrungsdauer der Anmeldeprotokolle fest und bestimmen Sie, wer sie lesen darf.
• Planen Sie den Ausstieg: Wie wechseln Personen und Anwendungen, wenn Sie den IdP verlassen?
• Informieren Sie die Nutzer:innen darüber, was bearbeitet wird.

Für Fragen zu Ihrer konkreten Rechtsgrundlage wenden Sie sich an Ihre Datenschutzberatung oder Ihren Rechtsbeistand.

Wo ein Studio hilft

Die Protokollarbeit ist Standard. Schwierig wird das Umfeld: Altanwendungen, die weder SAML noch OIDC sprechen, ein eigenes Portal, das SCIM-Schnittstellen braucht, Shop-, CRM- und ERP-Anbindungen, die sich alle auf eine Benutzeridentität einigen müssen. Ampersand ist ein Zürcher Studio, in dem erfahrene Entwickler:innen jedes Projekt vom ersten Kontakt bis zur Übergabe führen. Wir machen Systemintegrationen und API-Anbindungen für Shop, CRM und ERP sowie Replatforming und Migration von Altsystemen. Unsere Preisseite listet die Optionen für Anbindungen auf, von einer einzelnen Verbindung bis zum Integrationspaket, dazu einen Run-&-Monitor-Plan für CHF 750 pro Monat für die laufende Betreuung.

Häufige Fragen

Ist SSO dasselbe wie OAuth?

Nein. OAuth 2.0 ist ein Rahmenwerk für den delegierten Zugriff auf Ressourcen. SSO ist das Ergebnis einer einmaligen Anmeldung, geliefert durch SAML oder OpenID Connect. OpenID Connect baut auf OAuth 2.0 auf und ergänzt standardisierte Identitätsangaben.

Wie binde ich Single Sign-on in eine bestehende Anwendung ein?

Registrieren Sie die Anwendung in Ihrem Identitätsanbieter, wählen Sie SAML oder OIDC je nachdem, was die Anwendung unterstützt, ordnen Sie Claims und Rollen zu und weisen Sie eine kleine Testgruppe zu. Führen Sie eine vollständige Anmeldung als Test durch, machen Sie SSO dann verbindlich und überwachen Sie die Protokolle. Ergänzen Sie SCIM, wenn Konten automatisch deaktiviert werden sollen.

Ersetzt SSO die Benutzerprovisionierung?

Nein. SSO prüft die Identität bei der Anmeldung. Konten anzulegen und zu deaktivieren ist Aufgabe der Provisionierung, meist über SCIM. Ohne sie können Konten aktiv bleiben, nachdem jemand das Unternehmen verlassen hat.

Ist Single Sign-on sicher?

Es kann es sein, wenn Token geprüft werden, Sitzungen zeitlich begrenzt sind, ein zweiter Faktor verlangt wird und die Anmeldeaktivität überwacht wird. SSO bündelt das Risiko beim Identitätsanbieter und in den Token, deshalb brauchen diese den stärksten Schutz.

Welches Protokoll soll eine neue Webanwendung nutzen?

OpenID Connect passt zu modernen Webanwendungen, mobilen Apps und APIs. SAML 2.0 ist die Wahl, wenn die Unternehmenssysteme Ihrer Kund:innen oder die Anwendung eines Anbieters es verlangen. Viele Produkte unterstützen beides.

Quellen

• Microsoft defines SSO
• identity-provider-initiated flows
• Okta describes
• OAuth 2.0 is an authorization framework
• AGOV guidance
• Enterprise SSO Playbook
• Guard.ch’s setup guide
• listed in this Entra integration guide
• SAML just-in-time provisioning
• The SCIM guide notes
• Bynder’s support guide
• Auth0 explains
• security analysis by Doyensec
• signing keys are the root of trust