SAML vs OIDC (comparaison)

SAML 2.0 (Security Assertion Markup Language) et OIDC (OpenID Connect) sont les deux principaux protocoles de SSO fédéré. SAML — standard XML/SOAP émergé 2005, dominant historiquement enterprise. OIDC — couche identité sur OAuth 2.0 émergée 2014, JSON/REST, dominant moderne (consumer, mobile, SaaS).

Différences clés :
(1) **Format** — SAML XML (verbose, complex parsing) ; OIDC JSON Web Tokens (compact, simple).
(2) **Transport** — SAML via POST forms ou redirects, often signed assertions ; OIDC via REST APIs + redirects, ID tokens JWT.
(3) **Use cases primaires** — SAML enterprise SSO (Active Directory, Okta, Azure AD historical) ; OIDC mobile apps, SPAs, modern web, social login.
(4) **Mobile/SPA friendliness** — SAML clunky (XML on mobile = pain) ; OIDC designed mobile-first.
(5) **Complexity implementation** — SAML high (XML signatures, attribute mapping, metadata exchange) ; OIDC much simpler.
(6) **Security history** — SAML vulnerable XSW (XML Signature Wrapping) — multiple library CVEs ; OIDC vulnerable misconfigurations OAuth (redirect_uri, state parameter).
(7) **Identity providers** — both supported by all major IdPs (Okta, Auth0, Microsoft Entra ID, Google, Ping, etc.).

Quand préférer SAML : (1) integration with legacy enterprise apps SAML-only ; (2) regulated industries with SAML expertise ; (3) deep AD/ADFS integration.

Quand préférer OIDC : (1) new applications, especially mobile/SPA ; (2) social login (Google, Facebook, GitHub) ; (3) microservices auth ; (4) modern API access ; (5) developer experience priority.

Industry trend : OIDC dominating new development, SAML maintained for legacy compatibility. Many SaaS support both — startups deploy OIDC, enterprise customers request SAML. Identity platforms (Okta, Auth0) abstract both behind unified config. Compétences SC-300, AZ-500, CISSP.