SAML vs. OIDC: Wie Sie wählen und was wirklich zählt

Was SAML 2.0 eigentlich ist

SAML steht für Security Assertion Markup Language. Die Version 2.0 wurde 2005 von OASIS ratifiziert und ist seitdem das Rückgrat für webbasiertes SSO in Unternehmen.

Die Funktionsweise ist simpel, wenn man das XML einmal beiseite lässt. Ein Benutzer greift auf Ihre Anwendung zu – den Service Provider (SP) –, der nicht weiß, wer der Benutzer ist. Daher leitet er den Browser an den Identity Provider (IdP) weiter. Der IdP authentifiziert den Benutzer und erstellt eine Assertion: ein signiertes XML-Dokument, das angibt, wer der Benutzer ist, welche Attribute er besitzt und wie lange das Dokument gültig ist. Der Browser sendet dies per POST an die Assertion Consumer Service (ACS)-URL des SP, und der SP verifiziert die Signatur anhand des X.509-Zertifikats des IdP.

Daraus ergeben sich drei Eigenschaften, die erklären, warum das Protokoll bei vielen beliebt oder unbeliebt ist:

• Der Browser dient als Transportmittel. Es ist kein Back-Channel-Aufruf zwischen SP und IdP erforderlich, daher funktioniert SAML auch dann, wenn die beiden Server einander nicht erreichen können.
• Vertrauen basiert auf einem fest hinterlegten Zertifikat. Wenn dieses abläuft, fällt SSO für alle Benutzer gleichzeitig aus.
• Es ist ein Browser-Protokoll. SAML hat kein natives Konzept für ein API-Zugriffstoken.

Was OIDC eigentlich ist

OpenID Connect ist eine schlanke Identitätsschicht auf Basis von OAuth 2.0, die 2014 von der OpenID Foundation veröffentlicht wurde. OAuth 2.0 löste das Problem der delegierten Autorisierung und traf bewusst keine Aussage darüber, wer der Benutzer ist. OIDC ergänzt genau diesen Aspekt.

Der Ablauf entspricht dem OAuth-Authorization-Code-Flow mit einem zusätzlichen Scope: openid. Die App leitet den Benutzer an den Autorisierungs-Endpunkt des IdP weiter, der Benutzer authentifiziert sich und der IdP leitet mit einem kurzlebigen Autorisierungscodezurück. Die App ruft daraufhin über einen Back-Channel den Token-Endpunkt auf und tauscht diesen Code gegen ein Access Token, optional ein Refresh Token und ein ID-Token.

Das ID-Token macht den Unterschied zu OIDC aus: Es ist ein JSON Web Token, das mit JWS (typischerweise RS256) signiert ist und Felder wie sub, iss, aud, exp sowie in der Regel die E-Mail-Adresse enthält. Sie verifizieren es anhand eines Schlüssels vom JWKS-Endpunkt des IdP.

Zwei Eigenschaften sind entscheidend:

• Die Discovery erfolgt automatisch. Jeder konforme IdP veröffentlicht unter <issuer>/.well-known/openid-configuration eine Liste aller Endpunkte, sodass Ihre App diese ausliest, anstatt dass Sie URLs manuell in die Konfiguration kopieren müssen.
• Schlüssel rotieren automatisch. Der JWKS-Endpunkt stellt die aktuellen öffentlichen Schlüssel bereit. Wenn der IdP diese rotiert, zieht Ihre App automatisch nach. Niemand muss sich Ablaufdaten im Kalender notieren.

SAML vs. OIDC: Der Vergleich, auf den es ankommt

Welches Protokoll sollten Sie also wählen?

Die ehrliche Antwort, die man auf Vergleichsseiten der Anbieter meist vergeblich sucht:

Für die Anmeldung von Benutzern an einer browserbasierten Unternehmensanwendung funktionieren beide gleichermaßen gut, und der Sicherheitsunterschied ist vernachlässigbar. Beide sind ausgereift und sicher. Es gab noch keinen Sicherheitsvorfall, nur weil sich jemand für SAML statt OIDC entschieden hat.

Die Entscheidung wird Ihnen meist abgenommen. Wenn Ihr IdP-Team bereits vierzig SAML-Anwendungen und entsprechende Abläufe verwaltet, dauert die Einrichtung der einundvierzigsten Anwendung zwanzig Minuten, während die erste OIDC-Anwendung erst einmal ein Meeting erfordert. Gehen Sie den Weg des geringsten Widerstands.

Die technischen Unterschiede zeigen sich erst in den Randbereichen – aber diese Randbereiche sind real:

• Zertifikatsrotation ist der größte operative Kostenfaktor bei SAML. Ein unangekündigter Ablauf sperrt sofort alle Benutzer aus. Mit JWKS wird dies zum Randereignis.
• Nicht-Browser-Clients. Sobald eine mobile App, ein CLI oder eine SPA eine Authentifizierung benötigt, stößt SAML an seine Grenzen und Sie müssen eine Zwischenlösung bauen. OIDC mit PKCE erledigt das nativ.
• API-Token. SAML bestätigt die Identität, stellt aber kein Bearer-Token aus. Wenn derselbe Login anschließend API-Aufrufe autorisieren muss, erledigt OIDC diese Arbeit ohnehin.

Wo SAML immer noch punktet: es funktioniert, wenn SP und IdP sich nicht gegenseitig erreichen können, da der Browser alles überträgt – ein klassisches Beispiel ist ein lokales AD FS hinter einer Firewall.

Wo Teams Fehler machen

Die Wahl des Protokolls als Sicherheitsentscheidung zu betrachten. Teams verbringen Wochen mit der Entscheidung zwischen SAML und OIDC, aber nur zehn Minuten damit, ob der Gruppen-Claim ausgefüllt ist. Letzteres entscheidet darüber, wer was tun darf; Ersteres entscheidet nur, welches Konfigurationsmenü Sie ausfüllen müssen.

Davon auszugehen, dass Gruppen standardmäßig übertragen werden. Die meisten IdPs senden keinen Gruppen-Claim, es sei denn, Sie fügen ihn explizit hinzu. Zudem verwenden einige einen namensraumbezogenen Namen wie http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groups. Das SSO ist erfolgreich, alle landen in der Standardrolle und niemand bemerkt es eine Woche lang.

Zu ignorieren, wohin der Authentifizierungsverkehr fließt. Egal für welches Protokoll Sie sich entscheiden, irgendetwas empfängt die Assertion oder das ID-Token. Wenn sich dieses Etwas außerhalb Ihres Sicherheitsbereichs befindet, war das Protokoll nie die entscheidende Frage.

Want to see both paths side by side?

Spin up a TrueFoundry tenant and wire your IdP up over SAML or OIDC in one sitting.

Get started free

So funktioniert es in TrueFoundry

TrueFoundry unterstützt OIDC und SAML 2.0 gleichermaßen, mit Anleitungen für Entra ID, Okta, Google Workspace, JumpCloud, OneLogin, Auth0, Keycloak, AD FS, PingOne und Rippling sowie für benutzerdefiniertes SAML und OIDC.

Konfigurieren Sie es unter Plattform → Einstellungen → SSO: umschalten Aktiviert, wählen Sie Ihren SSO-Anbieter, und entscheiden Sie sich dann für OIDC oder SAML v2.

Die wichtigere Entscheidung: das Bereitstellungsmodell

Legen Sie vor der Wahl des Protokolls fest, wie der Authentifizierungsverkehr fließen soll.

Option 1 — TrueFoundry Auth Server plus Ihr IdP. Der Standard für SaaS und On-Premise. Der Auth-Server unter login.truefoundry.com fungiert als Vermittler zwischen Ihrer Control Plane und Ihrem IdP: Die Control Plane übergibt an den Auth-Server, dieser leitet an Ihren IdP weiter, validiert anschließend die Antwort, erstellt oder aktualisiert den Benutzerdatensatz und gibt Tokens zurück.

Lediglich die E-Mail-Adresse des Benutzers und eine Anforderungsanzahl erreichen login.truefoundry.com, was für Lizenzierung und Mandanten-Routing erforderlich ist. Im Gegenzug übernimmt TrueFoundry zentral die Besonderheiten von OIDC und SAML, die Schlüsselrotation sowie SCIM-Endpunkte, sodass Sie IdPs austauschen können, ohne eine erneute Bereitstellung durchzuführen. Anfragen an den IdP werden mit einem RS256-Schlüsselpaar signiert und die SAML-Ziel-Assertion ist aktiviert.

Option 2 – direkte IdP-Integration. Nur On-Premise, im Enterprise-Plan der höheren Stufe. Die Steuerungsebene kommuniziert direkt mit Ihrem IdP. login.truefoundry.com ist nicht eingebunden, und Benutzer-E-Mails sowie Anfragenzähler verlassen zu keinem Zeitpunkt Ihr Netzwerk. Die Steuerungsebene wird bei der Installation mit dem OIDC-Issuer oder den SAML-Metadaten Ihres IdP in den Helm-Werten konfiguriert, und Tokens werden lokal mit einem von unserem Support bereitgestellten INTERNAL_JWT_JWKS-Wert signiert.

Beide Optionen unterstützen dieselben IdPs und dieselben zwei Protokolle. Der einzige Unterschied besteht darin, ob der Authentifizierungsverkehr Ihre Netzwerkgrenze überschreitet – und genau diese Frage sollten Sie mit Ihrer Sicherheitsabteilung klären, nicht die Wahl zwischen XML und JWT.

Option 1: Der OIDC-Datenaustausch

Von TrueFoundry zu Ihrem IdP gibt es genau einen Wert, der für alle Kunden identisch ist:

https://login.truefoundry.com/oauth2/callback

Legen Sie diesen als Redirect URI, Sign-in Redirect URI oder Reply URL in Ihrer IdP-Anwendung fest.

Von Ihrem IdP zu TrueFoundry:

Dieser Schalter macht den Vorteil von OIDC konkret. Lassen Sie ihn aktiviert, damit TrueFoundry die Endpunkte für Autorisierung, Token, Userinfo und JWKS selbst ausliest. Deaktivieren Sie ihn nur, wenn Ihr IdP kein Discovery-Dokument bereitstellt – in diesem Fall müssen Sie alle vier Endpunkte manuell eingeben.

Option 1: Der SAML-Datenaustausch

SAML ist ein wechselseitiger Austausch, weshalb Sie die Konfiguration erst speichern und anschließend im IdP hinterlegen müssen.

Von Ihrem IdP zu TrueFoundry:

Dieser Hin-und-Her-Austausch ist der entscheidende Unterschied im Kleinen. OIDC benötigt eine einzige feste Callback-URL. SAML erfordert vier Werte, die in beide Richtungen übertragen werden, sowie ein Zertifikat, dessen Ablaufdatum nun in Ihrer Verantwortung liegt.

Claims: Der Teil, der über den Zugriff entscheidet

Unabhängig vom gewählten Protokoll liest TrueFoundry dieselben Attribute aus. Die Standardwerte sind email und sub, die unter folgendem Punkt überschrieben werden können: Erweiterte Felder anzeigen als E-Mail-Claim und Eindeutiger ID-Claim. groups ist der für RBAC verwendete Claim.

Anstatt die Claim-Namen in TrueFoundry zu überschreiben, sollten Sie diese auf der Seite des IdP als Alias definieren, damit die Standardeinstellungen funktionieren:

Wenn dies korrekt konfiguriert ist, erfolgt der Rest automatisch. Ein Claim-Wert wird einem Team über die Felder Identity Provider FQN und Claim-Wert zugeordnet – wenn Ihr IdP groups als Team-Claim verwendet und das Token ml-platform enthält, geben Sie hier ml-platform ein.

Dieses Team erhält dann Rollen: Weisen Sie ihm eine Mandantenrolle zu, damit jedes Mitglied diese erbt, oder vergeben Sie eine Ressourcenrolle über die Zugriffssteuerungsseite einer Ressource.

Diese Verknüpfung ist bei beiden Protokollen identisch. Informationen zum Rollenmodell finden Sie unter API-Authentifizierung und RBAC im Gateway, und für den Fall auf Tool-Ebene unter MCP-Zugriffssteuerung.

Option 2: dieselben Protokolle, konfiguriert in Helm

Hier erfolgt der Austausch der Felder in der values.yaml unter servicefoundryServer.env. Beide Protokolle benötigen zudem INCLUDE_TRUEFOUNDRY_MANAGED_JWKS: "false", INTERNAL_JWT_SERVICE_ENABLED: "true", INTERNAL_JWT_JWKS vom Support sowie ENABLE_EXTERNAL_OAUTH: "true" am Gateway.

OIDC: OAUTH_PROVIDER_TYPE: "EXTERNAL" sowie EXTERNAL_OAUTH_ISSUER, EXTERNAL_OAUTH_CLIENT_ID und EXTERNAL_OAUTH_CLIENT_SECRET. Die Redirect-URI lautet <CONTROL_PLANE_URL>/auth/callback, die Discovery muss unter <ISSUER_URL>/.well-known/openid-configuration erreichbar sein und die Standard-Scopes sind hier openid email profile offline_access.

SAML: OAUTH_PROVIDER_TYPE: "EXTERNAL_SAML" sowie EXTERNAL_SAML_IDP_ENDPOINT und ein base64-kodiertes EXTERNAL_SAML_CERTIFICATE. Die ACS-URL ist <CONTROL_PLANE_URL>/api/svc/v1/saml/acs und der Default Relay State ist <CONTROL_PLANE_URL>. Claims werden über EXTERNAL_SAML_EMAIL_CLAIM, EXTERNAL_SAML_UNIQUE_ID_CLAIM und EXTERNAL_SAML_GROUPS_CLAIM überschrieben, wobei EXTERNAL_SAML_ROLE_MAPPING_TENANT_ADMIN_GROUPS festlegt, welche Gruppen Tenant-Admin-Rechte erhalten. Bewahren Sie Geheimnisse in Kubernetes-Secrets auf.

Beim Logout sind die Unterschiede am größten. Bei OIDC erkennt TrueFoundry Ihren end_session_endpoint automatisch; Sie müssen lediglich <CONTROL_PLANE_URL> als Post-Logout-Redirect-URI registrieren, andernfalls gibt der IdP einen HTTP 400-Fehler zurück. Bei SAML erfordert das Single Logout die Erstellung eines SP-Signaturschlüsselpaars mit openssl, die Base64-Kodierung des privaten Schlüssels in EXTERNAL_SAML_SP_PRIVATE_KEY, das Hochladen des passenden Zertifikats und die Konfiguration der Single-Logout-URL des IdP auf <CONTROL_PLANE_URL>/api/svc/v1/saml/slo.

Tokens nach der Anmeldung

Nach dem Austausch setzt die Control Plane die Access- und Refresh-Tokens als HttpOnly-Cookies, und jede nachfolgende Anfrage verwendet diese zur Authentifizierung und Autorisierung.

Browser-Cookies mit accessToken und refreshToken, die von der Control Plane als HttpOnly gesetzt wurden

Die Standardlaufzeiten bei Option 1 betragen 1 Tag für das Access-Token und 7 Tage für das Refresh-Token, änderbar über den Support. Bei Option 2 (SAML) legt EXTERNAL_SAML_ACCESS_TOKEN_EXPIRY_SECONDS die Ablaufzeit des Access-Tokens fest (Standardwert: 3600 Sekunden). Deaktivierte Benutzer werden während des Auth-Flows abgewiesen, bei dem die IdP-Antwort dem Benutzer per E-Mail zugeordnet wird.

Ein Praxisbeispiel: Okta, SAML und ein Plattform-Team

Sie nutzen Okta, Ihr Sicherheitsteam hat sich auf SAML standardisiert und die Gruppe ml-platform soll Cluster verwalten, während alle anderen nur Lesezugriff erhalten.

1. Erstellen Sie die SAML-App in Okta mit Platzhalterwerten für die Single Sign-on URL und die Audience URI.
2. In TrueFoundryunter Plattform → Einstellungen → SSOaktivieren Sie SSO, wählen Sie Okta aus, entscheiden Sie sich für SAML v2und fügen Sie die SAML-SSO-URL von Okta sowie das X.509-Signaturzertifikat ein. Speichern.
3. Zurück in Oktaersetzen Sie die Platzhalter durch die Callback-URL und Issuer die TrueFoundry nun anzeigt.
4. Fügen Sie Attribut-Statements in Okta hinzu und ordnen Sie sub, email und groups zu.
5. Erstellen Sie ein Teamlegen Sie dessen Identity Provider FQN fest und setzen Sie den Claim-Wert auf ml-platform.
6. Weisen Sie diesem Team Cluster-Admin-Rechte zu über die Seite „Zugriffskontrolle“ des Clusters. Alle anderen verbleiben in der Standardrolle „Mitglied“, die lediglich über die Berechtigungen cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup und agent:CreateAgent verfügt.

Bei OIDC ändert sich in der Praxis kaum etwas: Die Schritte 1 bis 3 lassen sich zu einer festen Callback-URL und drei Feldwerten zusammenfassen, und die Schritte 4 bis 6 sind identisch. Das ist der tatsächliche Umfang dieser Protokollentscheidung.

Um Benutzer und Teams automatisch statt erst bei der ersten Anmeldung bereitzustellen, aktivieren Sie SCIM unter Einstellungen → Sicherheit & Zugriff → Bereitstellung, kopieren Sie anschließend die SCIM-Basis-URL, generieren Sie ein Bearer-Token und fügen Sie beides in Okta ein.

Seite „Einstellungen“, „Sicherheit und Zugriff“, „Bereitstellung“, auf der SCIM aktiviert ist

SCIM-Basis-URL, die im TrueFoundry SSO-Konfigurationsbereich angezeigt wird

‍