SSO mit SAML 2.0 und OIDC: Ein Login für Bexio, Microsoft 365 und KI-Apps

Was sind SAML und OIDC?

Single Sign-On (SSO) bezeichnet die Architektur, in der ein Benutzer sich einmal an einem zentralen Identity Provider anmeldet und danach Zugriff auf mehrere Anwendungen erhält, ohne sich erneut authentifizieren zu müssen. Die zwei dominanten Protokolle sind SAML 2.0 und OpenID Connect (OIDC).

SAML 2.0 (Security Assertion Markup Language, Version 2.0) ist seit 2005 standardisiert und das traditionelle Enterprise-Protokoll. Es überträgt Authentifizierungs-Aussagen (Assertions) als signierte XML-Dokumente zwischen Identity Provider (IdP) und Service Provider (SP). Der Browser des Benutzers ist der Transport-Kanal (HTTP-POST oder Redirect-Binding). SAML ist robust, weit verbreitet, aber XML-basiert und in modernen Web-/Mobile-Stacks unhandlich.

OIDC (OpenID Connect) ist eine Schicht über OAuth 2.0 und seit 2014 standardisiert. Es überträgt Identitäts-Aussagen als JSON Web Tokens (JWT), die kompakter sind als XML. Authentifizierungs-Flow läuft als HTTP-Redirect mit JSON-Antworten. OIDC ist heute (Mai 2026) das de-facto-Standard-Protokoll für neue Web-Apps, mobile Apps und Single-Page-Apps.

Die wichtigsten IdPs im CH-Treuhand-Markt sind: Microsoft Entra ID (früher Azure AD, über 60% Marktanteil bei CH-KMU), Google Workspace IdP (15-25%), Keycloak (Open-Source, für selbst-gehostete Setups), Authelia (lightweight Open-Source). Daneben Okta (vor allem in CH-Töchtern amerikanischer Konzerne) und Auth0 (heute Okta-Eigentum, beliebt bei SaaS-Anbietern).

Mai 2026 sind zwei Trends entscheidend. Erstens: Passkeys (WebAuthn / FIDO2) werden Standard für den Endbenutzer. Statt Passwort eingibt der Benutzer einen biometrischen Faktor (Fingerabdruck, Gesicht) oder einen Hardware-Key. Phishing-resistent und benutzer-freundlich. Zweitens: SCIM 2.0 (System for Cross-Domain Identity Management) wird Standard für User-Provisioning. Der IdP legt automatisch User-Accounts in den verbundenen Apps an, modifiziert sie und deaktiviert sie bei Austritt.

Warum es für CH-Treuhand wichtig ist

Eine typische CH-Treuhand-Stelle mit 10 Mitarbeitenden hat über 15 Werkzeuge im Einsatz: Microsoft 365, Bexio, eine Lohnbuchhaltungs-Software, ein CRM, ein Dokumenten-Management, eine Zeiterfassung, ein Büro-Tool für Bankzugänge, dazu mehrere KI-Tools (Beleg-Erkennung, Mandanten-Chat, Mahnwesen). Ohne SSO müssen Mitarbeitende für jede Anwendung ein eigenes Passwort verwalten. Das endet praktisch immer in Passwort-Wiederverwendung oder in Klebezetteln am Monitor.

SSO löst dieses Problem auf drei Ebenen. Erstens: ein Login. Der Mitarbeiter meldet sich morgens an Entra ID an und hat danach Zugang zu allen Tools, in denen sein Konto eingerichtet ist. Das senkt die tägliche Reibung spürbar.

Zweitens: ein Austritts-Schalter. Wenn ein Mitarbeiter die Stelle verlässt, deaktiviert der Admin den Account im IdP und alle verbundenen Apps werden in derselben Sekunde gesperrt. Das ist nach DSG und nach OR Art. 328b zwingend, wird in der Realität aber oft vergessen, wenn jede App ein eigenes Account-System hat.

Drittens: revisions-fähige Zugriffs-Logs. Jede Anmeldung wird im IdP geloggt: Wer, wann, welche App, welches Gerät, welcher IP-Bereich. Bei einem DSG-Vorfall haben Sie ein durchsuchbares Audit-Trail.

Konkretes Beispiel: Treuhand-Büros mit Bexio + Microsoft 365 + Custom-KI-App. Alle drei sind als Service-Provider in Entra ID eingebunden. Der Mitarbeiter klickt morgens auf das Bexio-Icon, wird zum Entra ID-Login geleitet, gibt Passkey ein, ist in Bexio drin. Beim Wechsel zur KI-App keine erneute Anmeldung nötig.

Wie es funktioniert

Beide Protokolle teilen die selbe Grund-Choreografie: Service Provider leitet Benutzer zum IdP, IdP authentifiziert, IdP gibt eine signierte Aussage an den Service Provider zurück.

SAML 2.0 im Detail: Der Service Provider (z.B. Bexio) erkennt, dass der Benutzer nicht angemeldet ist, und sendet einen SAML-AuthnRequest als HTTP-POST oder Redirect zum IdP. Der IdP (z.B. Entra ID) authentifiziert den Benutzer (Passwort, Passkey, MFA) und stellt eine SAML-Assertion aus: ein XML-Dokument mit Benutzer-Attributen (eMail, Name, Rollen), signiert mit dem privaten X.509-Schlüssel des IdP. Der Benutzer wird mit dieser Assertion zurück zum Service Provider geleitet, der die Signatur prüft und den Benutzer einloggt.

Der Trust zwischen IdP und SP wird über zwei Metadata-XMLs etabliert, die einmalig zwischen den Parteien getauscht werden: der IdP stellt sein X.509-Zertifikat und seinen Entity-Endpoint zur Verfügung, der SP genauso. Konfiguration erfolgt typisch im IdP-Admin-Center und im SP-Konfig-Bereich.

OIDC im Detail: Der SP (Relying Party, RP) leitet den Benutzer mit einem Authorization-Request zum IdP (Authorization Server). Der IdP authentifiziert und gibt einen Code zurück. Der SP tauscht den Code beim Token-Endpoint des IdP gegen ein ID-Token (JWT mit Benutzer-Claims wie sub, email, name) und ein Access-Token (für API-Calls). Die JWT-Signatur wird mit dem öffentlichen JWK (JSON Web Key) des IdP geprüft.

Ein Beispiel-Token-Tausch in OIDC:

```bash curl -X POST "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \ -d "client_id=$CLIENT_ID" \ -d "scope=openid profile email" \ -d "code=$AUTH_CODE" \ -d "grant_type=authorization_code" \ -d "redirect_uri=https://ihre-app.ch/callback" \ -d "client_secret=$CLIENT_SECRET" ```

Die Antwort enthält id_token, access_token und refresh_token. Der SP dekodiert das id_token, prüft die Signatur gegen den JWKS-Endpoint und legt den Benutzer-Session an.

SCIM-Provisioning läuft im Hintergrund: Der IdP kennt die SCIM-Endpoints der Apps und sendet bei jeder Benutzer-Änderung (User created, modified, disabled) einen REST-Call an die App.

SSO-Rollout in 5 Schritten

1. 01IdP wählen (Entra ID für Microsoft-365-Kunden, Google Workspace IdP für Google-Kunden, Keycloak für self-hosted Setups).
2. 02App-Inventar erstellen: Welche Apps sind im Einsatz, welche unterstützen SAML, welche OIDC, welche keines von beiden?
3. 03Pilot-App auswählen (typisch eine wenig kritische, z.B. das interne Wiki), SSO-Verknüpfung konfigurieren und 2 Wochen pilotieren.
4. 04Rollout auf alle Apps mit SSO-Support, jeden Schritt dokumentieren (Metadaten, OAuth-Client-IDs, Sign-Out-URL).
5. 05Passkeys einführen für neue Benutzer, SCIM-Provisioning für kritische Apps aktivieren, Lebenszyklus-Workflow (On-/Offboarding) im IdP abbilden.

Wann SSO einsetzen

Sobald drei oder mehr Werkzeuge im Einsatz sind, lohnt sich SSO. In Schweizer Treuhand-Stellen ab 5 Mitarbeitenden ist SSO heute praktisch Pflicht; die Kombination aus Microsoft 365 als IdP plus SAML- oder OIDC-Verknüpfung zu allen anderen Tools ist Standard.

Für neue Apps (KI-Tools, Custom-Dashboards) wählen Sie OIDC. Es ist einfacher zu implementieren (JSON statt XML, JWT-Bibliotheken in jeder Sprache) und besser für SPA- und Mobile-Apps geeignet. SAML ist die Wahl, wenn die App nur SAML unterstützt (oft bei älterer Enterprise-Software) oder wenn die IT-Abteilung historisch auf SAML standardisiert ist.

Passkeys aktivieren Sie ab Mai 2026 für alle neuen Benutzer. Bestehende Benutzer migrieren Sie schrittweise. Der Schritt von Passwort zu Passkey reduziert Phishing-Erfolge nach OWASP-Studien um über 90 Prozent.

SCIM aktivieren Sie ab 20 Mitarbeitenden. Unter dieser Schwelle ist der manuelle Provisioning-Aufwand vertretbar.

Wann NICHT

Für ein Ein-Personen-Büro ohne externe Apps ist SSO Overhead ohne klaren Nutzen. Hier reicht ein gut verwalteter Passwort-Manager.

Für Apps, die nur sporadisch genutzt werden und über keine sensiblen Daten verfügen, kann SSO einen disproportionierten Implementations-Aufwand bedeuten. Beispiel: ein kleines Marketing-Tool, das einmal pro Quartal verwendet wird. Hier ist Passwort plus Passwort-Manager günstiger.

Für Multi-Tenant-SaaS-Anbieter, die SSO als Premium-Feature verkaufen, kann die App eine SSO-Zusatz-Lizenz erfordern (das sogenannte "SSO-Tax-Problem"). Bei kleinen Volumina lohnt sich die Lizenz nicht. Prüfen Sie das vor der Anschaffung.

SAML 2.0 ist für komplett neue Apps die schlechtere Wahl. XML-Verarbeitung, Signatur-Prüfung und Metadaten-Tausch sind anfällig für Konfigurations-Fehler. Wenn die Wahl frei ist, nehmen Sie OIDC.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. OASIS: SAML 2.0 Core Specification · 2026-05
2. OpenID Foundation: OpenID Connect Core 1.0 · 2026-05
3. Microsoft Entra ID: SAML and OIDC integration guide (May 2026) · 2026-05
4. FIDO Alliance: Passkeys deployment guidance 2026 · 2026-04