SAML vs OIDC: How to Choose, and What Matters More

What SAML 2.0 actually is

SAML is the Security Assertion Markup Language. Version 2.0 was ratified by OASIS in 2005 and has been the backbone of enterprise web SSO since.

The mechanics are simple once you strip away the XML. A user hits your app — the service provider (SP) — which does not know who they are, so it redirects the browser to the identity provider (IdP). The IdP authenticates the user and produces an assertion: a signed XML document stating who the user is, what attributes they carry, and how long it is valid. The browser POSTs it to the SP’s Assertion Consumer Service (ACS) URL, and the SP verifies the signature against the IdP’s X.509 certificate.

Three properties follow, and they explain most of what people like and dislike:

• The browser is the transport. No back-channel call between SP and IdP is needed, so SAML works where the two servers cannot reach each other.
• Trust is a pinned certificate. When it expires, SSO breaks for everyone at once.
• It is a browser protocol. SAML has no native concept of an API access token.

What OIDC actually is

OpenID Connect is a thin identity layer on OAuth 2.0, published by the OpenID Foundation in 2014. OAuth 2.0 solved delegated authorization and deliberately said nothing about who the user is. OIDC adds that back.

The flow is the OAuth authorization code flow with one extra scope, openid. The app redirects to the IdP’s authorization endpoint, the user authenticates, and the IdP redirects back with a short-lived authorization code. The app then calls the token endpoint over a back channel and exchanges that code for an access token, optionally a refresh token, and an ID token.

The ID token is what makes it OIDC: a JSON Web Token signed with JWS, typically RS256, carrying sub, iss, aud, exp and usually email. You verify it against a key from the IdP’s JWKS endpoint.

Two properties matter:

• Discovery is automatic. Every compliant IdP publishes <issuer>/.well-known/openid-configuration listing every endpoint, so your app reads it instead of you pasting URLs into config.
• Keys rotate without you. The JWKS endpoint serves current public keys, so the IdP rotates and your app follows. Nobody diarises an expiry.

SAML vs OIDC: the comparison that matters

So which one should you pick

The honest version, which vendor comparison pages skip:

For signing users into a browser-based enterprise app, either works, and the security difference is negligible. Both are mature and signed. Nobody was breached because they chose SAML over OIDC.

The decision is usually made for you. If your IdP team has forty SAML apps and a runbook, adding a forty-first takes twenty minutes and your first OIDC app takes a meeting. Go with the grain.

The engineering difference only shows at the edges — but those edges are real:

• Certificate rotation is SAML’s biggest operational cost. An unannounced expiry locks out every user at once. JWKS makes it a non-event.
• Non-browser clients. The moment a mobile app, CLI or SPA needs to authenticate, SAML runs out of road and you build a shim. OIDC with PKCE handles it natively.
• API tokens. SAML asserts identity; it does not hand you a bearer token. If the same login must authorise API calls afterwards, OIDC is doing that work anyway.

Where SAML still wins: it works when SP and IdP cannot reach each other, because the browser carries everything — on-premises AD FS behind a firewall is the classic case.

Where teams get this wrong

Treating the protocol choice as a security decision. Teams spend weeks on SAML versus OIDC and ten minutes on whether the group claim is populated. The second decides who can do what; the first decides which config screen you fill in.

Assuming groups arrive by default. Most IdPs do not emit a groups claim unless you add it, and several emit it under a namespaced name like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groups. SSO succeeds, everyone lands in the default role, and nobody notices for a week.

Ignoring where the auth traffic goes. Whichever protocol you pick, something receives the assertion or the ID token. If that something sits outside your perimeter, the protocol was never the interesting question.

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

How this works in TrueFoundry

TrueFoundry supports OIDC and SAML 2.0 equally, with guides for Entra ID, Okta, Google Workspace, JumpCloud, OneLogin, Auth0, Keycloak, AD FS, PingOne and Rippling, plus Custom SAML and Custom OIDC.

Configure it under Platform → Settings → SSO: toggle Enabled, pick your SSO Provider, then choose OIDC or SAML v2.

The choice that matters more: the deployment model

Before the protocol, decide where the authentication traffic flows.

Option 1 — TrueFoundry Auth Server plus your IdP. The default, on SaaS and on-prem. The auth server at login.truefoundry.com sits between your control plane and your IdP: the control plane hands off to the auth server, which hands off to your IdP, then validates the response, creates or updates the user record, and returns tokens.

Only the user’s email and a request count reach login.truefoundry.com, for licensing and tenant routing. In exchange, TrueFoundry absorbs the OIDC and SAML quirks, key rotation and SCIM endpoints centrally, and you can swap IdPs without redeploying. Requests to the IdP are signed with an RS256 key pair, and SAML destination assertion is enabled.

Option 2 — direct IdP integration. On-prem only, on the higher-tier Enterprise plan. The control plane talks to your IdP directly. login.truefoundry.com is not in the loop, and user emails and request counts never leave your network. The control plane is configured at install time with your IdP’s OIDC issuer or SAML metadata in the Helm values, and tokens are signed locally with an INTERNAL_JWT_JWKS value support provides.

Both options support the same IdPs and the same two protocols. The only difference is whether auth traffic crosses your perimeter — and that is the question worth escalating to security, not XML versus JWT.

Option 1: the OIDC field exchange

From TrueFoundry to your IdP there is exactly one value, identical for every customer:

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

Set it as the Redirect URI, Sign-in redirect URI or Reply URL in your IdP application.

From your IdP to TrueFoundry:

That toggle is the OIDC advantage made concrete. Leave it on and TrueFoundry reads the authorization, token, userinfo and JWKS endpoints itself. Turn it off — only needed if your IdP publishes no discovery document — and you fill in all four by hand.

Option 1: the SAML field exchange

SAML is a two-way exchange, which is why you save first and fix the IdP afterwards.

From your IdP to TrueFoundry:

That round trip is the difference in miniature. OIDC needed one fixed callback URL. SAML needs four values moving both ways, plus a certificate whose expiry you now own.

Claims: the part that decides access

Whichever protocol you pick, TrueFoundry reads the same attributes. Defaults are email and sub, overridable under Show advanced fields as Email Claim and Unique ID Claim. groups is the claim used for RBAC.

Rather than overriding claim names in TrueFoundry, alias them on the IdP side so the defaults work:

Get that right and the rest is free. A claim value maps to a team through the team’s Identity Provider FQN and Claim Value fields — if your IdP uses groups as the team claim and the token carries ml-platform, you enter ml-platform here.

That team then carries roles: grant it a tenant role and every member inherits it, or grant a resource role from a resource’s Access Control page.

That join is identical on both protocols. For the role model see API auth and RBAC in the gateway, and for the tool-level case MCP access control.

Option 2: the same protocols, configured in Helm

Here the field exchange moves into values.yaml, under servicefoundryServer.env. Both protocols also need INCLUDE_TRUEFOUNDRY_MANAGED_JWKS: "false", INTERNAL_JWT_SERVICE_ENABLED: "true", INTERNAL_JWT_JWKS from support, and ENABLE_EXTERNAL_OAUTH: "true" on the gateway.

OIDC: OAUTH_PROVIDER_TYPE: "EXTERNAL" plus EXTERNAL_OAUTH_ISSUER, EXTERNAL_OAUTH_CLIENT_ID and EXTERNAL_OAUTH_CLIENT_SECRET. The redirect URI becomes <CONTROL_PLANE_URL>/auth/callback, discovery must be live at <ISSUER_URL>/.well-known/openid-configuration, and default scopes here are openid email profile offline_access.

SAML: OAUTH_PROVIDER_TYPE: "EXTERNAL_SAML" plus EXTERNAL_SAML_IDP_ENDPOINT and a base64-encoded EXTERNAL_SAML_CERTIFICATE. The ACS URL is <CONTROL_PLANE_URL>/api/svc/v1/saml/acs and Default Relay State is <CONTROL_PLANE_URL>. Claims override via EXTERNAL_SAML_EMAIL_CLAIM, EXTERNAL_SAML_UNIQUE_ID_CLAIM and EXTERNAL_SAML_GROUPS_CLAIM, with EXTERNAL_SAML_ROLE_MAPPING_TENANT_ADMIN_GROUPS naming which groups get tenant admin. Keep secrets in Kubernetes secrets.

Logout is where the gap is widest. With OIDC, TrueFoundry discovers your end_session_endpoint automatically; your only job is registering <CONTROL_PLANE_URL> as a post-logout redirect URI, and the IdP returns HTTP 400 if you skip it. With SAML, Single Logout means generating an SP signing key pair with openssl, base64-encoding the private key into EXTERNAL_SAML_SP_PRIVATE_KEY, uploading the matching certificate, and pointing the IdP’s Single Logout URL at <CONTROL_PLANE_URL>/api/svc/v1/saml/slo.

Tokens, once you are in

After the exchange, the control plane sets the access and refresh tokens as HttpOnly cookies, and every later request carries them for authentication and authorization.

Default lifetimes on Option 1 are 1 day for the access token and 7 days for the refresh token, changeable through support. On Option 2 SAML, EXTERNAL_SAML_ACCESS_TOKEN_EXPIRY_SECONDS sets the access token expiry and defaults to 3600 seconds. Deactivated users are rejected during the auth flow, where the IdP response is mapped to a user by email.

A worked example: Okta, SAML, and a platform team

You run Okta, your security team standardised on SAML, and the ml-platform group should administer clusters while everyone else gets a read baseline.

1. Create the SAML app in Okta with placeholder Single sign-on URL and Audience URI values.
2. In TrueFoundry, under Platform → Settings → SSO, enable SSO, pick Okta, choose SAML v2, and paste Okta’s SAML SSO URL plus its X.509 signing certificate. Save.
3. Back in Okta, replace the placeholders with the Callback URL and Issuer TrueFoundry now shows.
4. Add attribute statements in Okta mapping sub, email and groups.
5. Create a team, set its Identity Provider FQN, and set Claim Value to ml-platform.
6. Grant that team Cluster Admin from the cluster’s Access Control page. Everyone else stays on the default Member role, which carries only cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup and agent:CreateAgent.

Nothing here changes meaningfully with OIDC: steps 1 to 3 collapse into one fixed callback URL and three field values, and steps 4 to 6 are identical. That is the honest size of the protocol decision.

To provision users and teams automatically instead of on first login, turn on SCIM under Settings → Security & Access → Provisioning, then copy the SCIM Base URL, generate a Bearer token, and paste both into Okta.

Ready to wire up your IdP?

Configure SAML or OIDC, map your groups to teams, and have RBAC working the same afternoon.

Start free on TrueFoundry

Gotchas worth knowing

On Entra ID and Okta, SCIM requires SAML. This is the one case where the protocol debate has a real answer on TrueFoundry. If you are on either IdP and want automated provisioning, pick SAML — and decide before you build the OIDC app.

SCIM group names are constrained. The IdP group name becomes the team name: alphanumerics, hyphens and underscores only, up to 36 characters. ML Platform (EMEA) will not survive the trip.

Deleting an SSO config can fail with an error saying the configuration is out of sync with the central auth server. Retry the delete with force=true on the settings API, which needs Manage Settings on the tenant.

SAML Single Logout fails two predictable ways. A certificate that is not the public pair of EXTERNAL_SAML_SP_PRIVATE_KEY gives “Invalid Signature”; an SP Entity ID that does not exactly match <CONTROL_PLANE_URL> gives “Issuer does not match”.

Related reading

• API Auth and RBAC in the Gateway
• MCP Access Control — tool-level permissions, same role model
• Enterprise MCP Access Control — scaling across teams
• MCP Authentication — inbound and outbound auth
• AI Governance Framework

Conclusion

SAML versus OIDC is a smaller decision than its search volume suggests. Both sign users in safely and both are supported everywhere, so follow whatever your IdP team already operates. Reach for OIDC when you have mobile or single-page clients, need API tokens, or want to stop diarising certificate expiries. Stay on SAML when your organisation runs on it, when SP and IdP cannot reach each other, or when a feature you need ships only on that path.

The question worth more attention is where the authentication traffic goes. On TrueFoundry both protocols work identically on either deployment model — but only one keeps every login inside your network. In a regulated environment that is the line your auditor asks about, and it has nothing to do with XML.

Configure SSO on TrueFoundry

Free to start