SAML vs OIDC: Welke te kiezen en wat belangrijker is

Wat SAML 2.0 daadwerkelijk is

SAML staat voor Security Assertion Markup Language. Versie 2.0 werd in 2005 geratificeerd door OASIS en is sinds die tijd de ruggengraat van enterprise web SSO.

De werking is eenvoudig als u de XML even wegdenkt. Een gebruiker opent uw app — de service provider (SP) — die niet weet wie de gebruiker is. De app stuurt de browser daarom door naar de identity provider (IdP). De IdP authenticeert de gebruiker en genereert een assertion: een ondertekend XML-document dat vermeldt wie de gebruiker is, welke attributen deze heeft en hoelang het document geldig is. De browser POST dit naar de Assertion Consumer Service (ACS) URL van de SP, en de SP verifieert de handtekening aan de hand van het X.509-certificaat van de IdP.

Hieruit volgen drie eigenschappen die verklaren wat mensen er prettig of juist vervelend aan vinden:

• De browser is het transportmiddel. Er is geen back-channel communicatie tussen SP en IdP nodig, dus SAML werkt ook als de twee servers elkaar niet rechtstreeks kunnen bereiken.
• Vertrouwen is gebaseerd op een vastgezet certificaat. Wanneer dit verloopt, werkt SSO direct voor niemand meer.
• Het is een browserprotocol. SAML kent geen ingebouwd concept voor een API-access token.

Wat OIDC daadwerkelijk is

OpenID Connect is een dunne identiteitslaag bovenop OAuth 2.0, in 2014 gepubliceerd door de OpenID Foundation. OAuth 2.0 loste gedelegeerde autorisatie op, maar zei bewust niets over de identiteit van de gebruiker. OIDC voegt dat weer toe.

De flow is de OAuth-authorization code flow met één extra scope: openid. De app verwijst door naar het authorization endpoint van de IdP, de gebruiker authenticeert zich, en de IdP verwijst terug met een kortstondige authorization code. De app roept vervolgens via een back-channel het token endpoint aan en wisselt die code in voor een access token, optioneel een refresh token, en een ID token.

Het ID token maakt het OIDC: een JSON Web Token ondertekend met JWS (meestal RS256), dat sub, iss, aud, exp en meestal email bevat. U verifieert dit aan de hand van een sleutel van het JWKS-endpoint van de IdP.

Twee eigenschappen zijn hierbij van belang:

• Discovery verloopt automatisch. Elke IdP die aan de specificaties voldoet, publiceert <issuer>/.well-known/openid-configuration waarin alle endpoints worden vermeld. Uw app leest dit uit, waardoor u geen URL's handmatig in de configuratie hoeft te plakken.
• Sleutels roteren automatisch. Het JWKS-endpoint levert actuele openbare sleutels. Wanneer de IdP roteert, volgt uw app automatisch. Niemand hoeft vervaldata in de agenda te zetten.

SAML vs OIDC: de vergelijking die er toe doet

Welke moet u kiezen?

Eerlijk advies, wat leveranciers op vergelijkingspagina's vaak weglaten:

Voor het inloggen van gebruikers in een enterprise web-app werken beide prima en is het veiligheidsverschil verwaarloosbaar. Beide zijn volwassen en ondertekend. Er is nog nooit een datalek geweest puur omdat men SAML verkoos boven OIDC.

De keuze is vaak al voor u gemaakt. Als uw IdP-team al veertig SAML-apps en een draaiboek heeft, kost het toevoegen van een eenenveertigste twintig minuten, terwijl uw eerste OIDC-app een vergadering vereist. Kies de weg van de minste weerstand.

Het technische verschil wordt pas merkbaar in de randgevallen — maar die randgevallen zijn wel reëel:

• Certificaatrotatie is de grootste operationele kostenpost van SAML. Een onopgemerkte vervaldatum sluit alle gebruikers tegelijk uit. JWKS maakt dit probleemloos.
• Niet-browser clients. Zodra een mobiele app, CLI of SPA moet authenticeer, loopt SAML vast en moet u een tussenlaag bouwen. OIDC met PKCE ondersteunt dit standaard.
• API-tokens. SAML bevestigt de identiteit; het levert geen bearer token op. Als dezelfde login daarna API-calls moet autoriseren, voert OIDC dat werk sowieso al uit.

Waar SAML nog steeds wint: het werkt wanneer SP en IdP elkaar niet rechtstreeks kunnen bereiken, omdat de browser alle gegevens overdraagt — een on-premises AD FS achter een firewall is hiervan het klassieke voorbeeld.

Waar teams de mist in gaan

De protocolkeuze zien als een beveiligingsbeslissing. Teams besteden weken aan de keuze tussen SAML en OIDC, maar slechts tien minuten aan de vraag of de group claim wel juist gevuld is. Dat laatste bepaalt wie wat mag doen; het eerste bepaalt alleen welk configuratiescherm u invult.

Ervan uitgaan dat groepen standaard worden meegeleverd. De meeste IdP's sturen geen groups-claim mee tenzij u dit expliciet instelt, en verschillende leveranciers sturen dit onder een naam met een namespace, zoals http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groups. De SSO slaagt, iedereen krijgt de standaardrol, en niemand merkt het een week lang op.

Negeren waar het authenticatieverkeer naartoe gaat. Welk protocol u ook kiest, er is een onderdeel dat de assertion of het ID token ontvangt. Als dat onderdeel zich buiten uw netwerkperimeter bevindt, was het protocol nooit het belangrijkste vraagstuk.

Wilt u beide opties naast elkaar zien?

Start een TrueFoundry tenant op en koppel uw IdP in één sessie via SAML of OIDC.

Gratis aan de slag

Hoe dit werkt in TrueFoundry

TrueFoundry ondersteunt OIDC en SAML 2.0 gelijkwaardig, met handleidingen voor Entra ID, Okta, Google Workspace, JumpCloud, OneLogin, Auth0, Keycloak, AD FS, PingOne en Rippling, evenals Custom SAML en Custom OIDC.

Configureer dit via Platform → Settings → SSO: zet Enabled aan, kies uw SSO Provider, en kies vervolgens OIDC of SAML v2.

De keuze die belangrijker is: het implementatiemodel

Bepaal voordat u het protocol kiest hoe de authenticatiestroom moet lopen.

Optie 1 — TrueFoundry Auth Server in combinatie met uw IdP. De standaard bij SaaS en on-prem. De auth server op login.truefoundry.com bevindt zich tussen uw control plane en uw IdP: de control plane draagt over aan de auth server, die overdraagt aan uw IdP, vervolgens het antwoord valideert, het gebruikersrecord aanmaakt of bijwerkt, en tokens retourneert.

Alleen het e-mailadres van de gebruiker en het aantal verzoeken bereiken login.truefoundry.com, ten behoeve van licentiëring en tenant-routing. In ruil daarvoor verwerkt TrueFoundry de specifieke OIDC- en SAML-details, sleutelrotatie en SCIM-endpoints centraal, waardoor u van IdP kunt wisselen zonder opnieuw te hoeven deployen. Verzoeken naar de IdP worden ondertekend met een RS256-sleutelpaar, en SAML destination assertion is ingeschakeld.

Optie 2 — directe IdP-integratie. Uitsluitend on-prem, op het Enterprise-plan. De control plane communiceert rechtstreeks met uw IdP. login.truefoundry.com wordt niet gebruikt, en e-mailadressen en aantallen verzoeken verlaten uw netwerk nooit. De control plane wordt tijdens de installatie geconfigureerd met de OIDC issuer van uw IdP of SAML-metadata in de Helm-values, en tokens worden lokaal ondertekend met een INTERNAL_JWT_JWKS-waarde die door support wordt geleverd.

Beide opties ondersteunen dezelfde IdP's en dezelfde twee protocollen. Het enige verschil is of het authenticatieverkeer uw perimeter kruist — en dat is de vraag die u aan uw beveiligingsteam moet voorleggen, niet XML versus JWT.

Optie 1: OIDC-velden uitwisselen

Van TrueFoundry naar uw IdP is er precies één waarde, die voor elke klant identiek is:

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

Stel dit in als de Redirect URI, Sign-in redirect URI of Reply URL in uw IdP-applicatie.

Van uw IdP naar TrueFoundry:

Die schakelaar maakt het voordeel van OIDC concreet. Laat hem ingeschakeld en TrueFoundry leest zelf de authorization-, token-, userinfo- en JWKS-endpoints uit. Schakel hem uit — alleen nodig als uw IdP geen discovery document publiceert — en u moet alle vier de velden handmatig invullen.

Optie 1: SAML-velden uitwisselen

SAML is een uitwisseling in twee richtingen, wat de reden is dat u eerst opslaat en pas daarna de IdP instelt.

Van uw IdP naar TrueFoundry:

Dat proces laat het verschil in het klein zien. OIDC had voldoende aan één vaste callback-URL. SAML vereist vier waarden die in beide richtingen gaan, plus een certificaat waarvan u de vervaldatum nu zelf moet beheren.

Claims: het gedeelte dat de toegang bepaalt

Welk protocol u ook kiest, TrueFoundry leest dezelfde attributen uit. Standaard zijn dit email en sub, aanpasbaar onder Show advanced fields als Email Claim en Unique ID Claim. groups is de claim die wordt gebruikt voor RBAC.

In plaats van claimnamen in TrueFoundry te overschrijven, kunt u deze beter aan de IdP-zijde als alias instellen, zodat de standaardinstellingen werken:

Als u dat goed instelt, werkt de rest vanzelf. Een claimwaarde wordt gekoppeld aan een team via de velden Identity Provider FQN en Claim Value van het team — als uw IdP groups gebruikt als team-claim en het token ml-platform bevat, vult u hier ml-platform in.

Dat team krijgt vervolgens rollen toegewezen: ken het een tenantrol toe en elk lid erft deze, of ken een ressourcerol toe vanaf de Access Control-pagina van een ressource.

Deze koppeling is identiek bij beide protocollen. Zie voor het rollenmodel API auth and RBAC in the gateway, en voor de toepassing op tool-niveau MCP access control.

Optie 2: dezelfde protocollen, geconfigureerd in Helm

Hier verschuift de velden-uitwisseling naar values.yaml, onder servicefoundryServer.env. Beide protocollen vereisen ook INCLUDE_TRUEFOUNDRY_MANAGED_JWKS: "false", INTERNAL_JWT_SERVICE_ENABLED: "true", INTERNAL_JWT_JWKS via support, en ENABLE_EXTERNAL_OAUTH: "true" op de gateway.

OIDC: OAUTH_PROVIDER_TYPE: "EXTERNAL" plus EXTERNAL_OAUTH_ISSUER, EXTERNAL_OAUTH_CLIENT_ID en EXTERNAL_OAUTH_CLIENT_SECRET. De redirect-URI wordt <CONTROL_PLANE_URL>/auth/callback, discovery moet actief zijn op <ISSUER_URL>/.well-known/openid-configuration, en de standaard scopes zijn hier openid email profile offline_access.

SAML: OAUTH_PROVIDER_TYPE: "EXTERNAL_SAML" plus EXTERNAL_SAML_IDP_ENDPOINT en een base64-gecodeerd EXTERNAL_SAML_CERTIFICATE. De ACS URL is <CONTROL_PLANE_URL>/api/svc/v1/saml/acs en de Default Relay State is <CONTROL_PLANE_URL>. Claims worden overschreven via EXTERNAL_SAML_EMAIL_CLAIM, EXTERNAL_SAML_UNIQUE_ID_CLAIM en EXTERNAL_SAML_GROUPS_CLAIM, waarbij EXTERNAL_SAML_ROLE_MAPPING_TENANT_ADMIN_GROUPS bepaalt welke groepen tenant admin-rechten krijgen. Bewaar geheimen in Kubernetes secrets.

Uitloggen toont het grootste verschil. Bij OIDC detecteert TrueFoundry uw end_session_endpoint automatisch; u hoeft alleen <CONTROL_PLANE_URL> te registreren als post-logout redirect URI. Als u dit overslaat, geeft de IdP een HTTP 400-fout. Bij SAML vereist Single Logout dat u een SP-sleutelpaar genereert met openssl, de privésleutel base64-codeert in EXTERNAL_SAML_SP_PRIVATE_KEY, het bijbehorende certificaat uploadt, en de Single Logout URL van de IdP laat wijzen naar <CONTROL_PLANE_URL>/api/svc/v1/saml/slo.

Tokens zodra u bent ingelogd

Na de uitwisseling stelt de control plane de access en refresh tokens in als HttpOnly cookies, en elk volgend verzoek bevat deze voor authenticatie en autorisatie.

De standaard levensduur bij Optie 1 is 1 dag voor het access token en 7 dagen voor het refresh token, aanpasbaar via support. Bij Optie 2 SAML bepaalt EXTERNAL_SAML_ACCESS_TOKEN_EXPIRY_SECONDS de levensduur van het access token, met een standaardwaarde van 3600 seconden. Gedeactiveerde gebruikers worden geweigerd tijdens de authenticatielogica, waarbij de IdP-respons op basis van e-mailadres aan een gebruiker wordt gekoppeld.

Een uitgewerkt voorbeeld: Okta, SAML en een platformteam

U gebruikt Okta, uw beveiligingsteam heeft gestandaardiseerd op SAML, en de groep ml-platform moet clusters beheren terwijl alle andere gebruikers leestoegang krijgen.

1. Maak de SAML-app aan in Okta met tijdelijke waarden voor Single sign-on URL en Audience URI.
2. In TrueFoundry, onder Platform → Settings → SSO, schakelt u SSO in, kiest u Okta, selecteert u SAML v2, en plakt u Okta's SAML SSO URL en het X.509-handtekeningcertificaat. Sla dit op.
3. Ga terug naar Okta en vervang de tijdelijke waarden door de Callback URL en Issuer die TrueFoundry nu toont.
4. Voeg attribute statements toe in Okta die sub, email en groups mappen.
5. Maak een team aan, stel de Identity Provider FQN in, en stel Claim Value in op ml-platform.
6. Wijs dit team Cluster Admin-rechten toe vanaf de Access Control-pagina van het cluster. Alle andere gebruikers behouden de standaard rol Member, die alleen cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup en agent:CreateAgent bevat.

Dit verandert niet wezenlijk bij OIDC: stappen 1 tot 3 worden teruggebracht tot één vaste callback-URL en drie veldwaarden, en stappen 4 tot 6 zijn exact hetzelfde. Dat is het daadwerkelijke verschil bij de protocolkeuze.

Om gebruikers en teams automatisch te provisionen in plaats van bij de eerste inlog, schakelt u SCIM in onder Settings → Security & Access → Provisioning. Kopieer vervolgens de SCIM Base URL, genereer een Bearer token, en plak beide in Okta.

Klaar om uw IdP te koppelen?

Configureer SAML of OIDC, koppel uw groepen aan teams en zorg dat RBAC nog dezelfde middag werkt.

Start gratis op TrueFoundry

Aandachtspunten die u moet weten

Bij Entra ID en Okta vereist SCIM SAML. Dit is de enige situatie waarin de protocoldiscussie op TrueFoundry een concreet antwoord heeft. Als u een van deze IdP's gebruikt en automatische provisioning wilt, kies dan voor SAML — en bepaal dit voordat u een OIDC-app bouwt.

SCIM-groepsnamen zijn beperkt. De groepsnaam in de IdP wordt de teamnaam: alleen alfanumerieke tekens, koppeltekens en underscores, tot maximaal 36 tekens. ML Platform (EMEA) zal de overgang niet doorstaan.

Het verwijderen van een SSO-configuratie kan mislukken met een foutmelding dat de configuratie niet synchroon loopt met de centrale auth server. Probeer het verwijderen opnieuw met force=true via de settings API, waarvoor Manage Settings op de tenant vereist is.

SAML Single Logout kan op twee voorspelbare manieren mislukken. Een certificaat dat niet het openbare paar is van EXTERNAL_SAML_SP_PRIVATE_KEY geeft "Invalid Signature"; een SP Entity ID dat niet exact overeenkomt met <CONTROL_PLANE_URL> geeft "Issuer does not match".

Gerelateerde artikelen

• API Auth and RBAC in the Gateway
• MCP Access Control — rechten op tool-niveau, hetzelfde rollenmodel
• Enterprise MCP Access Control — schalen over meerdere teams
• MCP Authentication — inkomende en uitgaande authenticatie
• AI Governance Framework

Conclusie

SAML versus OIDC is een minder ingrijpende beslissing dan het zoekvolume doet vermoeden. Beide laten gebruikers veilig inloggen en worden overal ondersteund, dus volg de lijn die uw IdP-team al hanteert. Kies voor OIDC wanneer u mobiele of single-page clients heeft, API-tokens nodig heeft, of geen certificaatvervaldata meer wilt bijhouden. Blijf bij SAML als uw organisatie hierop draait, wanneer SP en IdP elkaar niet rechtstreeks kunnen bereiken, of wanneer een specifieke functie die u nodig heeft alleen via die route beschikbaar is.

De vraag die meer aandacht verdient, is waar het authenticatieverkeer naartoe stroomt. Op TrueFoundry werken beide protocollen identiek in elk implementatiemodel — maar er is er slechts één die elke login binnen uw eigen netwerk houdt. In een gereguleerde omgeving is dat het punt waar uw auditor naar vraagt, en dat heeft niets met XML te maken.

Configureer SSO op TrueFoundry

Gratis om te starten