OIDC oder SAML: welches Sie wirklich brauchen

Jedes Team, das B2B-Software baut, steht an derselben Weggabelung, sobald ein ernstzunehmender Kunde zum ersten Mal sagt: „Wir brauchen SSO." Zwei Akronyme, OIDC und SAML, beide beanspruchen, die Antwort zu sein, und ein Internet voller Vergleichstabellen, die Ihnen erzählen, SAML sei „Enterprise" und OIDC sei „modern" und Sie genauso ratlos zurücklassen wie zuvor. Hier ist die Version, die Ihnen wirklich hilft, etwas auszuliefern.

Was sie sind

SAML stammt aus dem Jahr 2005 und ist XML. Ein Identity Provider signiert eine Assertion („das ist alice@bigco.com, hier sind ihre Gruppen") und schickt sie an Ihre App, die die Signatur prüft und sie anmeldet. Es wurde für den Browser und für Workforce-Identity gebaut, in einer Zeit, in der „das Unternehmen" ein On-Premises-Active Directory und einen SOAP-Stack bedeutete. Es ist umständlich, es ist alt, und es ist in großen Organisationen absolut überall – und das ist die eine Tatsache daran, die für Sie zählt.

OIDC stammt aus dem Jahr 2014 und ist JSON und JWTs, aufgesetzt auf OAuth 2.0. Ein Identity Provider stellt ein ID-Token aus, das Ihre App validiert. Es wurde für das moderne Web gebaut: SPAs, mobile Apps, APIs, Social Login. Es ist sauberer, besser spezifiziert für die Dinge, die Sie heute tatsächlich bauen, und das Protokoll, das die meisten Identity-Projekte auf der grünen Wiese inzwischen sprechen.

Wann welches gewinnt

Die ehrliche Antwort auf „welches soll ich bauen" lautet: Sie haben fast nie die Wahl. Sie bauen das, was die IT-Abteilung Ihres Kunden ausgewählt hat – und sie hat es ausgewählt, lange bevor sie je von Ihnen gehört hat.

• Ein Kunde auf Okta, Entra ID oder Google Workspace kann meist beides, und OIDC ist der angenehmere Weg.
• Ein Kunde mit einem älteren ADFS, einem veralteten On-Premises-IdP oder einer 2016 verfassten Beschaffungs-Checkliste reicht Ihnen einen Brocken SAML-Metadaten und eine Kalendereinladung – und damit ist die Diskussion beendet.
• Ihre eigenen First-Party-Apps, Ihr Dashboard und Ihr Mobile-Client, wollen OIDC, Punkt. Sie würden niemals zu SAML greifen, um einen Nutzer in Ihrer eigenen React-App anzumelden.

Das Feld teilt sich also sauber auf: OIDC für das Moderne und das First-Party, SAML für „weil das Unternehmen es so verlangt". Verkaufen Sie an genug Unternehmen, und Sie werden nach beidem gefragt. Nicht irgendwann. Immer wieder.

Die Fallstricke – und hier wird Selbstbauen teuer

SAMLs Problem ist, dass es ein Protokoll mit signiertem XML ist, und signiertes XML gehört zum Verlässlich-Gefährlichsten in der angewandten Kryptografie. Die Wege, die SAML-Signaturprüfung falsch zu machen, sind zahlreich und berüchtigt:

• Signature Wrapping (XSW): Ein Angreifer verschiebt das signierte Element und schiebt eine unsignierte, gefälschte Assertion genau dorthin, wo Ihr Parser tatsächlich liest. Wenn Sie die Signatur prüfen und die Assertion in zwei getrennten Schritten lesen, sind Sie wahrscheinlich angreifbar – und fast jede erste Implementierung macht genau das.
• Kanonisierung und Comment Injection: die Bug-Klasse von 2018, bei der user@company.com<!---->.evil.com für die Signaturprüfung auf eine Weise kanonisiert wird und für die Zeichenkette, die Ihr Code liest, auf eine andere – sodass Sie fröhlich die falsche Person authentifizieren. Echte CVEs, mehrere große Bibliotheken.
• Die leiseren: die Response signieren, aber nicht die Assertion; unsignierte Assertions akzeptieren; dem vom IdP gelieferten Issuer vertrauen, ohne ihn zu pinnen; das Gültigkeitsfenster der Assertion falsch setzen. Jeder davon ist ein eigener Fallstrick, und jeder ist schon von Leuten, die wussten, was sie tun, in Produktion ausgeliefert worden.

OIDC ist deutlich vernünftiger, aber nicht frei von scharfen Kanten. Sie müssen immer noch die richtigen Claims validieren (iss, aud, exp, die nonce), PKCE verwenden, den längst toten Implicit Flow ablehnen und JWKS rotieren und cachen, ohne ein Token zurückzuweisen, das mit einem Schlüssel signiert wurde, den Sie noch nicht abgerufen haben. Der Unterschied ist, dass OIDCs Fallen dokumentiert, JSON-förmig und in den meisten Bibliotheken standardmäßig korrekt behandelt sind. SAMLs Fallen sind XML-förmig und haben Sicherheitsteams verschlungen, die weit besser ausgestattet waren als Ihres.

Die wahre Antwort

„OIDC oder SAML" ist die falsche Frage, denn die richtige Antwort für ein B2B-Produkt lautet „ja". Ihre modernen Kunden und Ihre eigenen Apps wollen OIDC. Ihre Enterprise-Kunden werden SAML vorschreiben, nach einem Zeitplan, den Sie nicht kontrollieren. Bauen Sie für eines, und der dritte Verkaufstermin macht es kaputt.

Was Sie wirklich brauchen, ist eine Möglichkeit, das jeweils mitgebrachte Protokoll jedes Kunden anzunehmen, ohne zwei Stacks, zwei Sätze Metadaten-Klempnerei und zwei voneinander unabhängige Gelegenheiten aufzustellen, die Signaturprüfung falsch zu machen. Die Implementierung ist der Preis. Die Wahl war nie der schwere Teil.

Genau diesen Teil nimmt Authagonal Ihnen ab. Jeder Tenant bekommt SAML 2.0 mit Metadaten-Import per Klick und OIDC-Föderation mit den Providern, die Ihre Kunden ohnehin betreiben, auf demselben Login, ohne Gebühr pro Verbindung für beides. Sie implementieren keine XML-Signaturprüfung, Sie hüten keinen JWKS-Cache, und Sie bauen nichts davon neu, wenn der nächste Kunde auftaucht und das andere Protokoll spricht. Sehen Sie, was enthalten ist.