7 Schritte zu Single Sign-on für individuelle Apps für Engineers und Produktmanager

7 Schritte zu Single Sign-on für individuelle Apps für Engineers und Produktmanager

Für neue individuelle Web- oder Mobile-Apps verwenden Sie OpenID Connect mit dem Authorization-Code-plus-PKCE-Flow; reservieren Sie SAML für Fälle, in denen Sie mit Legacy-Identitätsprovidern von Unternehmen interoperieren müssen. Halten Sie vor dem Schreiben von Code Folgendes bereit: eine registrierte Redirect-URI, eine Client-ID, eine Issuer- oder Metadaten-URL sowie Zugriff auf den JWKS-Endpunkt des Providers. Stellen Sie sicher, dass PKCE die S256-Methode verwendet, Tokens auf eine einzelne Audience beschränkt sind und sowohl Nonce- als auch State-Parameter beim Callback validiert werden.

Kurz gesagt:

• Verwenden Sie für neue cloudnative Apps OpenID Connect mit Authorization Code und PKCE und reservieren Sie SAML ausschließlich für Legacy-Integrationen in Unternehmen.
• Bestätigen Sie die vollständige PKCE-Validierung, beschränken Sie die Token-Audience und validieren Sie bei jedem Callback die Nonce- und State-Parameter, um die Sicherheit zu gewährleisten.
• Unterstützen Sie bei Bedarf beide Protokolle, verwenden Sie für moderne Apps jedoch standardmäßig OIDC – insbesondere bei API- und mobilen Architekturen – und unterstützen Sie SAML für Unternehmenspartner.
• Registrieren Sie Anwendungen ordnungsgemäß, validieren Sie Issuer und JWKS und testen Sie die Gültigkeit der Tokens sowie die Uhrzeitsynchronisierung vor dem Produktiveinsatz. Halten Sie separate Staging- und Produktionsumgebungen vor.
• Implementieren Sie eine sorgfältige Logout-Validierung, überwachen Sie häufige Fehler wie Abweichungen bei Redirect-URIs und bereiten Sie sich mit detaillierten Betriebs-Runbooks auf Zertifikatsrotationen vor.

Inhaltsverzeichnis

• Auswahl zwischen OIDC und SAML für individuelle Anwendungen
• Schrittweise Implementierung von OpenID Connect für individuelle Apps
• Integration von SAML 2.0 für Identitätsprovider von Unternehmen
• Authorization Code plus PKCE richtig umsetzen
• Wo Tokens gespeichert werden sollten: BFF-, SPA- und mobile Muster
• Logout und Sitzungsbeendigung korrekt handhaben
• Test-Checkliste und häufige Fehler bei der SSO-Bereitstellung
• Sicherheitsstandards, auf die sich jedes SSO-Designreview beziehen sollte
• Eine operative Checkliste aus der Umsetzungsarbeit
• Hilfe bei der Implementierung von SSO für Ihre individuelle Anwendung erhalten
• Quellen
• FAQ

Auswahl zwischen OIDC und SAML für individuelle Anwendungen

Die Protokollentscheidung hängt in der Regel davon ab, welche Art von App Sie entwickeln und mit wem sie kommunizieren muss. OpenID Connect wird für neue cloudnative Anwendungen empfohlen, da es auf OAuth 2.0 aufbaut und sich natürlich in Web- und API-Architekturen einfügt. SAML 2.0 ist in B2B-Integrationen von Unternehmen weiterhin verbreitet, insbesondere wenn der Identitätsprovider bereits seit Jahrzehnten besteht und das Integrationsteam keine Modernisierung plant.

Die Abwägungen sind praktischer, nicht philosophischer Natur. SAML basiert auf dem Austausch von XML-Metadaten und zertifikatsbasiertem Vertrauen, wodurch Zertifikatsrotation und Attributzuordnung zu wiederkehrenden Wartungsaufgaben werden. OIDC setzt auf JSON-Web-Tokens und ein Discovery-Dokument, mit denen die meisten aktuellen Bibliotheken deutlich weniger individuellen Code benötigen.

Vor der Entscheidung für ein Protokoll in Ihrer gesamten App sollten Sie einige Punkte abwägen:

• App-Architektur: Single-Page-Apps, mobile Apps und API-first-Backends passen natürlicher zum Token-Modell von OIDC als zu den Browser-Redirect-Annahmen von SAML.
• IdP-Landschaft der Partner: Wenn Ihre Unternehmenskunden ausschließlich SAML-Endpunkte bereitstellen, müssen Sie SAML unabhängig von Ihren eigenen Präferenzen unterstützen.
• Komplexität von Multi-Tenant-Umgebungen: Planen Sie Issuer-Lookup, Domänenverifizierung und Home-Realm-Discovery frühzeitig ein, wenn Sie mehrere Kunden-IdPs unterstützen, da eine nachträgliche Umstellung des Tenant-Routings nach dem Launch mühsam ist.

Die meisten Teams unterstützen letztlich beide Protokolle: OIDC als Standard und SAML als Anpassung für bestimmte Unternehmenskonten.

Schritt-für-Schritt-Implementierung von OpenID Connect für benutzerdefinierte Apps

Sobald Sie sich für OIDC entschieden haben, ist die Implementierungsabfolge bei den verschiedenen Anbietern weitgehend einheitlich – unabhängig davon, ob Sie Okta, Azure AD oder eine andere Identitätsplattform verwenden.

1. Anwendung registrieren bei Ihrem Identitätsanbieter und dabei den Clienttyp (öffentlich oder vertraulich), die exakten Weiterleitungs-URIs und die für CORS zulässigen Ursprünge angeben.
2. Discovery-Dokument abrufen vom /.well-known/openid-configuration Endpunkt des Anbieters und die URLs des Issuers und der JWKS zwischenspeichern.
3. Issuer validieren bei jedem empfangenen Token und exakt mit dem Wert im Discovery-Dokument abgleichen.
4. Den openid Scope mindestens anfordern und profile oder email nur hinzufügen, wenn Ihre App diese Claims tatsächlich benötigt.
5. Den Authorization-Code-Flow mit PKCE initiieren, indem Sie vor der Weiterleitung des Benutzers einen Code-Verifier und eine mit S256 gehashte Code-Challenge generieren.
6. Den zurückgegebenen id_tokenvalidieren und dabei iss, aud, expsowie den von Ihnen zu Beginn des Flows generierten nonce prüfen, wie es die OAuth2-Empfehlungen von OWASP nahelegen.
7. Secrets angemessen verwalten: Vertrauliche Clients speichern das Client-Secret ausschließlich serverseitig; öffentliche Clients verlassen sich stattdessen vollständig auf PKCE.

Einige Details bei der Bereitstellung führen bei Teams, die Staging-Umgebungen überspringen, zu Problemen: Bei den meisten Anbietern müssen Weiterleitungs-URI-Allowlists exakt übereinstimmen, sodass eine Abweichung durch einen abschließenden Schrägstrich unbemerkt fehlschlägt oder einen kryptischen Fehler auslöst. Eine Zeitabweichung zwischen Ihrem Server und dem IdP kann dazu führen, dass gültige Tokens als abgelaufen abgelehnt werden. Testen Sie mit einem Staging-IdP-Mandanten und einer eigenen Clientregistrierung, bevor Sie Produktionsanmeldedaten verwenden.

Profi-Tipp: Verwenden Sie getrennte Clientregistrierungen für Staging und Produktion, selbst wenn dies den doppelten Einrichtungsaufwand bedeutet: Eine gemeinsame Weiterleitungs-URI-Allowlist für mehrere Umgebungen ist eine häufige Ursache für Überraschungen nach dem Muster „In Staging hat es funktioniert“.

SAML 2.0 für Identitätsanbieter im Unternehmensumfeld integrieren

SAML-Integrationen folgen einem anderen Ablauf und basieren auf dem Austausch von Metadaten statt auf Discovery-Endpunkten. Für die Einrichtung von SAML-SSO müssen Weiterleitungs- und ACS-URLs registriert, Metadaten oder Zertifikate ausgetauscht und die Issuer-Werte zwischen Dienstanbieter und Identitätsanbieter abgeglichen werden. Abweichungen hierbei sind die häufigste Ursache für fehlgeschlagene Anmeldungen.

Praktische Schritte für eine saubere Integration:

• SP- und IdP-Metadaten frühzeitig austauschen einschließlich der URL des Assertion Consumer Service (ACS) und Ihrer Entity ID, damit beide Seiten wissen, wohin Assertions gesendet werden.
• Zertifikate gezielt verwalten: Rufen Sie sie, sofern verfügbar, über den Metadaten-Endpunkt des IdP ab, statt ein Zertifikat fest zu hinterlegen, das irgendwann abläuft.
• SAML-Attribute zuordnen und mithilfe einer expliziten Allowlist in das Autorisierungsmodell Ihrer App überführen. Testen Sie die Zuordnung mit einem eigens dafür vorgesehenen Testbenutzer pro Mandant, bevor Sie sie für echte Konten ausrollen.

SAML-spezifische Fehler lassen sich meist auf einige wenige Ursachen zurückführen: nicht signierte oder falsch signierte Assertions, eine Zeitabweichung zwischen IdP und Ihrem Server sowie Abweichungen bei der Zielgruppenbeschränkung, wenn der in der Assertion vorgesehene Empfänger nicht mit Ihrer Entity ID übereinstimmt.

Profi-Tipp: Protokollieren Sie während der Integrationstests die rohe SAML-Antwort (ohne vertrauliche Attributwerte). Probleme mit XML-Namespace sind in einer rohen Payload wesentlich leichter zu erkennen als in einem Stacktrace, der drei Ebenen vom eigentlichen Assertion-Objekt entfernt ist.

Authorization Code mit PKCE korrekt umsetzen

PKCE schließt eine konkrete Sicherheitslücke: Ohne PKCE kann derjenige, der einen abgefangenen Authorization Code erbeutet hat, diesen einlösen. PKCE bindet die ursprüngliche Autorisierungsanfrage über einen Verifier an den Token-Austausch, sodass selbst ein gestohlener Code ohne den passenden Verifier nutzlos ist. Der Authorization-Code-Flow mit PKCE gilt inzwischen als grundlegende Sicherheitsmaßnahme für Public Clients, wobei S256 als Methode für die Code-Challenge gegenüber der schwächeren Methode plain empfohlen wird.

Die Abläufe sind unkompliziert, sobald Sie sie einmal implementiert haben: Generieren Sie einen zufälligen Code-Verifier, hashen Sie ihn mit SHA-256, um die Code-Challenge zu erzeugen, senden Sie die Challenge in der Autorisierungsanfrage und übermitteln Sie den ursprünglichen Verifier, wenn Sie den Code gegen Tokens austauschen. Die Punkte, bei denen Teams häufig Fehler machen:

• Überspringen der Nonce-Validierung, wodurch eine der wichtigsten Schutzmaßnahmen gegen Replay-Angriffe in der OIDC-Schicht unwirksam wird.
• Wiederverwenden des Codes, obwohl ein Code nur einmal verwendet und nach dem ersten Austauschversuch sofort ungültig gemacht werden sollte.
• Unsichere Speicherung des Verifiers, etwa an einem Ort, auf den jedes Skript zugreifen kann, das in einer browserbasierten Anwendung auf der Seite ausgeführt wird.

Confidential Clients, also serverseitige Anwendungen, die ein Secret sicher verwahren können, kombinieren PKCE in vielen Implementierungen weiterhin mit einem Client-Secret. Public Clients wie SPAs und native mobile Apps verlassen sich allein auf PKCE, da sie ein Secret nicht vertraulich halten können.

Wo Tokens gespeichert werden sollten: BFF-, SPA- und Mobile-Muster

Die Platzierung von Tokens bestimmt maßgeblich, wie stark Ihre Anwendung dem Diebstahl von Tokens ausgesetzt ist. Das Backend-for-Frontend-Muster hält Tokens serverseitig und stellt dem Browser stattdessen ein kurzlebiges HttpOnly-Cookie aus – eine Konfiguration, die inzwischen als Standardempfehlung für Single-Page-Apps gilt, die private APIs aufrufen.

RFC 9700 beschreibt sendergebundene, kryptografisch gebundene Tokens als eine sich herausbildende Richtung zur Verringerung des Replay-Risikos, was darauf hindeutet, dass Designentscheidungen zur Token-Verarbeitung heute mögliche strengere Bindungsanforderungen berücksichtigen sollten.

Praktische Regeln für die Token-Topologie:

• Confidential Clients bewahren Secrets serverseitig auf; Public Clients verwenden statt eines Secrets PKCE und kurzlebige Access-Tokens.
• Beschränken Sie Access-Tokens auf eine einzelne Audience für jede API und akzeptieren Sie niemals ein ID-Token so, als wäre es ein API-Access-Token.
• Rotieren Sie Refresh-Tokens bei jeder Verwendung und erkennen Sie die Wiederverwendung eines ausgemusterten Tokens als mögliches Anzeichen für einen Diebstahl.

Mobile Apps folgen im Allgemeinen dem Public-Client-Modell und speichern Tokens im sicheren Speicher der jeweiligen Plattform (Keychain unter iOS, Keystore unter Android) statt in einfachen Dateien.

Logout und Sitzungsbeendigung korrekt handhaben

Single Logout klingt einfach, bis Sie berücksichtigen, wer ihn initiiert hat und wie weit er sich ausbreiten soll. Beim SP-initiierten Logout teilt Ihre Anwendung dem IdP mit, dass die Sitzung des Benutzers beendet ist; beim IdP-initiierten Logout weist der IdP jede verbundene Anwendung an, die Sitzung zu beenden. In beiden Richtungen muss die eingehende Nachricht validiert werden.

SAML Single Logout erfordert eine sorgfältige Validierung von Logout-Anfragen, da naive Implementierungen Denial-of-Service- oder erzwungene Logout-Risiken schaffen, bei denen ein Angreifer eine nicht authentifizierte Logout-Nachricht sendet, um einen legitimen Benutzer abzumelden.

Implementieren Sie den Logout mit folgenden Schutzvorkehrungen:

• Validieren Sie jede Logout-Anfrage auf Signatur und id_token_hint bevor Sie darauf reagieren.
• Behandeln Sie den globalen Logout als Best-Effort-Vorgang: Bereinigen Sie die lokale Sitzung sofort und versuchen Sie anschließend, Benachrichtigungen an nachgelagerte Systeme zu senden, statt auf diese zu warten.
• Speziell bei SAMLmüssen Logout-Anfragen signiert sein; konfigurieren Sie den SLO-Endpunkt ausdrücklich, statt einen Standardwert vorauszusetzen.

Test-Checkliste und häufige Fehler bei der SSO-Bereitstellung

Arbeiten Sie vor dem Go-Live eine kurze Vorab-Checkliste durch, statt Probleme erst in der Produktion zu entdecken.

1. Bestätigen Sie, dass die Redirect-URIs exakt übereinstimmen, einschließlich abschließender Schrägstriche und des Protokolls.
2. Aussteller und Metadaten überprüfen zwischen der Konfiguration Ihrer Anwendung und den tatsächlich vom IdP veröffentlichten Angaben abgleichen.
3. JWKS-Verfügbarkeit prüfen und bestätigen, dass Ihre Anwendung Signaturschlüssel abrufen und zwischenspeichern kann.
4. Serveruhren synchronisieren, da bereits eine Abweichung von wenigen Minuten zu einer fehlgeschlagenen Token-Validierung führt.
5. Mit einem Staging-IdP-Mandanten testen und dedizierte Konten verwenden, bevor Sie Produktionsanmeldedaten einsetzen.

Häufige Fehler lassen sich bestimmten Behebungen zuordnen: invalid_redirect_uri bedeutet fast immer eine Abweichung beim exakten Abgleich in der Allowlist, und eine Abweichung beim Aussteller bedeutet in der Regel, dass Ihre Anwendung ein veraltetes Discovery-Dokument zwischengespeichert hat. Protokollieren Sie Authentifizierungsereignisse einschließlich Fehlern und Wiederverwendungsversuchen, ohne jemals unverschlüsselte Token in Protokollen zu speichern.

Sicherheitsstandards, auf die sich jede SSO-Designprüfung beziehen sollte

Eine Handvoll Dokumente sollte jedes SSO-Design und jede Sicherheitsprüfung als Grundlage verwenden. RFC 9700 legt die aktuelle Sicherheitsbaseline für OAuth 2.0 fest, und RFC 7636 definiert den PKCE-Mechanismus, von dem diese Baseline abhängt. Die OAuth- und OIDC-Leitlinien der OWASP ASVS behandeln die OAuth- und OIDC-Schicht als eigenständigen Sicherheitsperimeter, der separat geprüft werden sollte.

Kontrollen, die in jeder Prüfung durchgesetzt werden sollten:

• Jedes Token auf eine Zielgruppe beschränken und auf der Seite des Ressourcenservers Token ablehnen, die nicht für diesen ausgestellt wurden.
• Stärkere Client-Authentifizierung bevorzugen beispielsweise private_key_jwt oder gegenseitiges TLS anstelle gemeinsam genutzter Geheimnisse, sofern Ihr Anbieter dies unterstützt.
• Zertifikate und Refresh-Token rotieren nach einem festen Zeitplan und den Widerruf sowie die Erkennung von Wiederholungen implementieren, statt sich allein auf den Ablauf von Token zu verlassen.

Profi-Tipp: Legen Sie 30 Tage vor dem Ablauf eines SAML-Zertifikats eine Kalendererinnerung an. Der Ablauf eines Zertifikats ist ein vermeidbarer Ausfall und keine Überraschung.

Eine operative Checkliste aus der Projektumsetzung

SSO in einer Demo zum Laufen zu bringen, ist der einfache Teil. Dafür zu sorgen, dass es einen Produktivstart, eine Zertifikatsrotation und einen IdP-Ausfall sechs Monate später übersteht, erfordert etwas mehr Disziplin.

• Staging und Produktion vollständig trennen mit getrennten Client-Registrierungen, Testbenutzerkonten und Metadatenendpunkten.
• Ein Runbook für die Zertifikatsrotation erstellen mit Überschneidungszeiträumen und Warnungen 30 Tage vor dem Ablauf; automatisieren Sie dabei die Übernahme von Metadaten von Metadatenendpunkten, sofern der Anbieter dies unterstützt.
• Eine vollständige Dokumentation übergeben, einschließlich eines Runbooks für den Token-Widerruf, Überwachungsdashboards für Authentifizierungsfehler und Abnahmetests, die das Team des Kunden nach jeder Änderung erneut ausführen kann.

Teams, die auf die Dokumentation zur Übergabe verzichten, lernen diese Lektionen meist während eines Vorfalls erneut statt an einem ruhigen Dienstagnachmittag.

Unterstützung bei der Implementierung von SSO für Ihre individuelle Anwendung erhalten

Wenn Ihr Team das Design ausgearbeitet hat, aber Unterstützung bei der Umsetzung benötigt, übernimmt Ridiculous Engineering den gesamten Prozess: Architekturprüfung, OIDC- oder SAML-Implementierung, Tests mit Staging-IdP-Mandanten sowie die Einrichtung von Runbook und Überwachung, die den Betrieb nach dem Launch sicherstellt. Wir arbeiten mit individuellen Softwareentwicklungsprojekten in einer Größe, die zum jeweiligen Problem passt, statt mit einer festen Vorlage, und erklären einen Zielkonflikt lieber ehrlich, als eine Abkürzung zu überverkaufen. Wenn Sie abwägen, ob Sie dies intern entwickeln oder ein Team hinzuziehen sollten, das bereits Erfahrungen mit den Problemen bei der Zertifikatsrotation und Abweichungen bei Callback-URLs gesammelt hat, kontaktieren Sie uns über unsere Kontaktseite und wir besprechen, was Ihre Anwendung tatsächlich benötigt.

Quellen

• RFC 9700: Bewährte aktuelle Sicherheitspraktiken für OAuth 2.0
• Microsoft Entra Single Sign-On (SSO)
• OAuth2 – OWASP Cheat Sheet Series

FAQ

Wie erstelle ich mein eigenes SSO?

Sie implementieren SSO, indem Sie Ihre App über OpenID Connect oder SAML in einen Identity Provider integrieren, anstatt die Authentifizierung von Grund auf selbst zu entwickeln. Für neue Apps ist OpenID Connect mit dem Authorization-Code- und PKCE-Flow der übliche Ausgangspunkt. Die Umsetzung erfolgt über Provider-SDKs, etwa von Okta oder Azure AD.

Ist SSO riskant?

SSO ist nicht grundsätzlich riskanter als app-spezifische Logins und reduziert Risiken typischerweise, da die Authentifizierung bei einem Provider mit stärkeren Sicherheitskontrollen gebündelt wird, als die meisten einzelnen Apps allein aufbauen könnten. Das eigentliche Risiko liegt in Implementierungsfehlern, etwa dem Überspringen von PKCE, der fehlenden Validierung der Token-Audience oder dem fehlerhaften Umgang mit dem Logout – all dies wird in OWASP’s OAuth2-Leitfaden direkt behandelt.

Kann man SSO in einer mobilen App verwenden?

Ja, mobile Apps implementieren SSO üblicherweise als öffentliche OAuth-2.0-Clients mit dem Authorization-Code-Flow und PKCE, da sie ein Client Secret nicht sicher speichern können. Tokens werden in der Regel im nativen sicheren Speicher der Plattform und nicht in einfachen App-Dateien gespeichert.

Wer sind die führenden SSO-Anbieter?

Zu den gängigen Identity Providern für SSO-Integrationen gehören unter anderem Okta und Microsofts Azure AD (jetzt Teil von Microsoft Entra). Die richtige Wahl hängt davon ab, welche Protokolle Ihre App unterstützen muss und welche Provider Ihre Unternehmenskunden bereits verwenden.

Wie funktioniert Single Logout appübergreifend?

Single Logout kann von Ihrer App (SP-initiiert) oder vom Identity Provider (IdP-initiiert) eingeleitet werden. In beiden Fällen muss die Logout-Nachricht validiert werden, bevor darauf reagiert wird. Naive SAML-Logout-Implementierungen können Risiken durch Denial-of-Service oder erzwungene Logouts verursachen. Daher behandeln die meisten Teams den globalen Logout als Best Effort und nicht als garantiert sofortigen Kill-Schalter für jede verbundene App.

Empfohlen

• KI-Speed-Engineering-Frameworks
• Was macht eine App wirklich fesselnd? Hier ist unser Geheimrezept!
• Projektmanager, Product Owner und Business-Analyst im E-Commerce und in der Anwendungsentwicklung: Welche Rolle benötigen Sie?