OIDC vs SAML decision guide
TL;DR
Use OIDC if your tool is a modern SaaS application, web application, or mobile platform, and it has a field for a discovery URL or OIDC issuer.
Use SAML if your tool is a legacy enterprise platform, requires corporate federation at the directory level, or only offers a SAML SSO settings screen.
If your tool supports both, prefer OIDC. It is simpler to configure, easier to debug, and is the direction the industry is moving.
What the protocols are
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. After authentication, LuxID issues a signed JSON Web Token (ID token) containing the user's claims. The tool verifies the token cryptographically without calling LuxID again. Most modern tools support OIDC natively or with a lightweight plugin.
SAML 2.0 is an XML-based federation protocol. After authentication, LuxID posts a signed XML assertion to the tool's Assertion Consumer Service (ACS) URL. SAML is the dominant standard in enterprise software built before 2015 and remains the only option for some Microsoft 365 and legacy ServiceNow scenarios.
Both protocols result in the same outcome for the user: they click "Sign in with LuxID", authenticate at login.luxid.lu, and are redirected back to your tool already logged in.
Decision Matrix
Verified against vendor documentation as of May 2026. Vendor product names and admin-console paths change; if you find a mismatch, file a doc issue.
| Tool | Recommended protocol | Reason |
|---|---|---|
| Odoo | OIDC | Native auth_oauth module since Odoo 10, OIDC since Odoo 16. |
| WordPress (plugin) | OIDC | Native plugin support (daggerhart, miniorange); discovery URL simplifies setup |
| Drupal (contrib module) | OIDC | The OpenID Connect (opens in a new tab) contrib module is the standard path for Drupal 9/10/11. SAML alternative via simplesamlphp_auth. |
| Salesforce | OIDC | Auth Providers feature natively supports OIDC |
| Moodle | OIDC | OAuth2 plugin is the supported path |
| ServiceNow | OIDC (preferred), SAML also supported | Multi-Provider SSO supports both as first-class; single-provider SAML is deprecated. |
| Atlassian Cloud (Jira, Confluence, Bitbucket) | SAML 2.0 | Atlassian Guard (the renamed Atlassian Access) is SAML-only for SSO; no native OIDC. |
| Atlassian Data Center | Either | SAML SSO app or OIDC depending on product and version |
| Microsoft 365 / Entra External ID (workforce direct federation) | SAML 2.0 (or WS-Fed) | Microsoft explicitly does not support OIDC for tenant-to-tenant federation. |
| Microsoft Entra External ID (customer tenants, CIAM) | OIDC | Custom OIDC identity providers supported in customer (CIAM) tenants only. |
| Splunk (Cloud Platform and Enterprise) | SAML 2.0 | SAML is the supported user-SSO protocol; OAuth/OIDC is only for programmatic API access, not interactive sign-in. |
| Grafana (Cloud and self-hosted OSS/Enterprise) | OIDC (Generic OAuth) | OIDC available on all tiers; SAML available on Grafana Enterprise and Cloud only. Pick SAML only if you need IdP-initiated flows or SAML SLO. |
| Canva (Canva Enterprise) | SAML 2.0 (mandatory) | Canva Enterprise supports SAML 2.0 and SCIM only; no OIDC option. |
| Figma (Organization and Enterprise) | SAML 2.0 (mandatory) | Figma supports SAML 2.0 and SCIM only; no OIDC path. |
| Generic modern SaaS (post-2018) | OIDC | Most expose OIDC discovery; SAML only required for the SAML-only categories above |
| Legacy enterprise (pre-2015) | SAML | OIDC may not be available |
| Custom application you are building | OIDC | See the Authenticate section instead of this section |
Where SAML is still strictly necessary in 2026
SAML cannot be replaced by OIDC in several well-defined categories:
- Design and creative SaaS: Canva Enterprise and Figma Organization/Enterprise ship SAML-only with no announced OIDC roadmap.
- Atlassian Cloud (Jira, Confluence, Bitbucket) via Atlassian Guard.
- Microsoft 365 / Entra workforce cross-tenant federation: Entra External ID direct federation and M365 guest access require SAML 2.0 or WS-Fed; OIDC federation between Entra workforce tenants is explicitly not supported. (OIDC works inside Entra External ID customer tenants only.)
- Government and regulated identity frameworks: FedRAMP, Login.gov, NIST SP 800-63C, eIDAS national eID schemes, eduGAIN and InCommon academic federations - these mandate or strongly assume SAML 2.0.
- Legacy enterprise applications: Oracle EBS, SAP NetWeaver, PeopleSoft, older on-premises ServiceNow installations typically expose SAML before OIDC.
Conversely, OIDC has decisively won for developer tools, observability platforms (Grafana, etc.), modern SaaS, mobile and SPA clients, and customer-facing CIAM scenarios. LuxID supports both protocols as first-class options; SAML coverage is not going away this decade.
Protocol comparison
Claim flexibility
How LuxID releases claims. Both protocols release the same set of claims, defined once in your Application's Claim Template on the LuxID side. LuxID ignores the
scopeparameter that an OIDC client sends at runtime: the released set is determined by the Claim Template, not by what the client asks for. This is a deliberate privacy guardrail - it stops a Partner from quietly broadening the data it collects by adding scopes to its requests. Adding a new claim is a Claim Template change, not a code change, and requires a request to LuxID (which reviews against the Ethical Code of Conduct and the agreed Permitted Use).
In practice the differences between OIDC and SAML on the claim axis are about shape, not granularity:
- OIDC delivers claims as JSON fields inside the ID token and/or the UserInfo response. Names follow the OIDC standard claim vocabulary (
given_name,family_name,email, ...). - SAML delivers claims as a flat XML attribute statement inside a signed SAML assertion. Names follow your tool's expected attribute names, mapped on the LuxID side.
Winner: neither, on this axis - the released set is identical. OIDC is generally easier to consume in modern code; SAML maps more directly into legacy enterprise role-mapping screens.
Configuration complexity
OIDC with discovery is the simplest possible configuration: one URL (https://login.luxid.lu/.well-known/openid-configuration) and the tool auto-fills every endpoint. Add Client ID, Client Secret, and claim mapping - done.
OIDC without discovery requires entering each endpoint manually: authorisation, token, UserInfo, and JWKS. Still manageable.
SAML requires bilateral metadata exchange: you import LuxID's IdP metadata XML into your tool, and you export your tool's SP metadata (or at minimum Entity ID + ACS URL) to LuxID. Both sides must complete their configuration before testing can begin.
Winner: OIDC for setup speed.
Token lifetime and session behaviour
LuxID issues OIDC tokens with the following lifetimes:
- ID token: ~1 hour
- Access token: short-lived
- Refresh token: long-lived (issued when
offline_accessis in the scope parameter)
SAML assertions do not carry a refresh token equivalent. Session duration is controlled by the tool's own session policy. For long-lived sessions, OIDC with refresh tokens gives the tool more control.
Winner: OIDC for session management flexibility.
Enterprise access control
SAML attribute-based access control (ABAC) is well understood by enterprise security teams. Tools like ServiceNow and Atlassian have mature SAML role-mapping configurations that read a SAML attribute (e.g. memberOf or department) and assign a local role.
OIDC achieves the same via claims, but configuration varies by tool. Older enterprise tools may only expose SAML role-mapping in their UI even if they technically support OIDC.
Winner: SAML for enterprise tools with existing SAML ABAC policies.
Standards trajectory
OIDC is the direction of travel. Major SaaS vendors are deprecating SAML in favour of OIDC. For new integrations where both protocols are available, choosing OIDC reduces future maintenance effort.
Trade-offs summary
| Factor | OIDC | SAML |
|---|---|---|
| Discovery-based auto-configuration | Yes | No |
| Setup speed | Fast | Slower (bilateral exchange) |
| Released claim set | Same on both - controlled by Claim Template | Same on both - controlled by Claim Template |
| Refresh token support | Yes | No equivalent |
| Legacy enterprise tool support | Limited | Broad |
| Microsoft 365 federation | No (use SAML) | Yes |
| Industry trajectory | Preferred | Legacy |
Decision flowchart
If your target is itself an identity broker
If the tool you are integrating is not a leaf SaaS application but an identity broker or federation hub - such as Keycloak, FusionAuth, or a Synapse Matrix homeserver - the OIDC vs SAML question is largely moot: all three support OIDC natively and that is the recommended protocol. The more important question is the operational shape of the integration. When LuxID sits upstream of a broker, the broker re-issues its own tokens to downstream applications, logout propagates across two hops, and user provisioning happens inside the broker's own user store rather than inside your application. These concerns are specific enough to warrant their own guide. See Identity broker integrations for step-by-step recipes for Keycloak, FusionAuth, and Synapse, plus a generic OIDC broker configuration.
Next steps
- If your tool has a dedicated guide: Tool-specific integrations
- If your tool is OIDC-compatible but not listed: Generic OIDC setup
- If your tool is SAML-compatible but not listed: Generic SAML setup
- If your tool is an identity broker or federation hub: Identity broker integrations
- For deep protocol reference: the Authenticate section