OIDC vs SAML — quoi choisir en 2026 ?

Trois acteurs dominent l'Identity Provider (IdP) d'entreprise en 2026 : Microsoft Entra ID (anciennement Azure AD), Okta, et — dans une moindre mesure — Google Workspace via Cloud Identity. À côté, des stacks open-source comme Keycloak et Authelia s'installent dans les organisations qui veulent garder la main sur leur IdP.

Tous supportent à la fois OpenID Connect (OIDC, basé sur OAuth 2.0) et SAML 2.0. Le choix du protocole côté SaaS dépend autant du profil client cible que de la maturité technique de l'équipe qui implémente.

OpenID Connect est une couche d'identité bâtie sur OAuth 2.0. Le flow standard (Authorization Code + PKCE) ressemble à ceci :

1. L'utilisateur clique « Se connecter avec mon organisation » sur votre SaaS.
2. Votre application redirige vers l'IdP avec un code_challenge PKCE.
3. L'utilisateur s'authentifie chez l'IdP (mot de passe, MFA, passkey, etc.).
4. L'IdP redirige vers votre callback avec un code à usage unique.
5. Votre backend échange ce code (+ le code_verifier PKCE) contre un ID Token (JWT signé) et un access token.
6. L'ID Token contient les claims standard : sub, email, name, groups (si configuré).

Tout est en JSON, les tokens sont des JWT vérifiables via un endpoint jwks_uri, et le discovery (/.well-known/openid-configuration) automatise la configuration côté client.

SAML 2.0 (Security Assertion Markup Language) est plus ancien — standardisé en 2005. Le flow le plus courant est SP-initiated avec POST binding :

1. L'utilisateur clique « SSO » sur votre SaaS (le Service Provider, SP).
2. Votre SaaS génère une SAML AuthnRequestXML signée et la POST à l'IdP via un formulaire HTML auto-soumis.
3. L'utilisateur s'authentifie chez l'IdP.
4. L'IdP renvoie une SAML ResponseXML signée contenant l'assertion (identité + attributs).
5. Votre backend valide la signature XML, vérifie les conditions (NotBefore, NotOnOrAfter, audience), et extrait les attributs.

Le tout en XML, avec de la signature XMLDSig et optionnellement du chiffrement XMLEnc. Le discovery équivalent existe via les metadata XMLpubliées par l'IdP.

1. Format & complexité d'implémentation

OIDC = JSON + JWT. SAML = XML + XMLDSig (signature XML canonique). En 2026, presque tous les développeurs connaissent JSON et JWT ; XMLDSig est rare et toujours source de vulnérabilités d'implémentation (XML Signature Wrapping, XML External Entity).

2. Maturité des bibliothèques

OIDC : SDK officiels dans tous les langages mainstream (Java spring-security-oauth2-client, Node openid-client, Python authlib, Go go-oidc). SAML : moins de choix, qualité inégale (la lib OneLogin Python a eu plusieurs CVE critiques 2020-2024).

3. Mobile & SPA

OIDC supporte nativement les apps mobiles et SPA via PKCE. SAML est conçu pour des Server Providers server-side ; l'adapter à une SPA demande un proxy côté backend, ce qui annule beaucoup de l'intérêt SAML.

4. Tokens et sessions

OIDC fournit un access token + refresh token natifs (rotation, revocation). SAML ne définit que l'assertion d'authentification — la gestion de session reste à la charge du SP.

5. Conformité réglementaire

Les deux passent en SOC 2 et ISO 27001. Pour le secteur bancaire et public, SAML reste préféré historiquement — pas pour des raisons techniques, mais parce que les IdP en place sont SAML depuis 10+ ans et les équipes IAM préfèrent ne pas migrer.

6. Logout (Single Logout)

SAML 2.0 a un Single Logout (SLO) standardisé mais rarement implémenté proprement. OIDC a un RP-Initiated Logout et un Back-Channel Logout (RFC 8417) plus modernes et mieux supportés.

7. Coût et tarification IdP

Sur Okta, Entra ID Premium et Auth0, le SAML est souvent réservé aux plans payants haut de gamme ; OIDC est inclus dans les plans standard. Pour vos clients, supporter OIDC en plus de SAML réduit leur facture IdP.

Microsoft Entra ID

Support natif OIDC et SAML, tooling d'admin équivalent. Le marketplace Entra contient des templates OIDC pré-configurés pour beaucoup de SaaS. Pour un nouveau SaaS B2B : OIDC est le path par défaut documenté par Microsoft.

Okta

Excellent support des deux. Okta Integration Network pré-configure votre SaaS si vous publiez un template OIDC. L'outillage de provisioning SCIM est plus mature en OIDC qu'en SAML.

Auth0 (Okta CIC)

Conçu OIDC-first dès l'origine, supporte SAML par rétrocompatibilité. Cible plutôt les SaaS B2C/PME ; les grands comptes restent sur Entra ou Okta.

Google Workspace / Cloud Identity

OIDC excellent (c'est l'une des premières implémentations historiques). SAML possible mais moins bien intégré que sur Entra/Okta.

Keycloak (open-source)

Support natif des deux protocoles, riche en patterns de fédération (identity brokering vers d'autres IdP, first-broker login, etc.). C'est notre IdP côté Architecture Platform.

Quand un SaaS B2B supporte plusieurs IdP — un par tenant client — il faut router l'utilisateur vers le bon. C'est le rôle du Home Realm Discovery. Trois patterns courants :

Pattern 1 — Sous-domaine par tenant

acme.your-saas.comroute directement vers l'IdP du tenant Acme. Très clair pour l'utilisateur, demande du wildcard DNS et du multi-tenant routing en frontend.

Pattern 2 — Email domain

Sur l'écran de login, l'utilisateur saisit son email. Selon le domaine (@acme.com → Entra ID Acme), votre backend redirige vers le bon IdP. Pattern Auth0 / Microsoft, plus opaque mais self-service.

Pattern 3 — Tenant sélecteur explicite

L'utilisateur choisit son organisation dans une liste. Simple, mais ne scale pas au-delà de quelques dizaines de tenants.

Migrer SAML → OIDC (côté SaaS)

Si votre SaaS supporte SAML depuis longtemps et veut ajouter OIDC : c'est un ajout, pas une migration destructive. Vous maintenez les deux endpoints en parallèle. Les tenants existants restent sur leur config (souvent SAML), les nouveaux clients choisissent OIDC. À 18-24 mois, vous proposez la migration client-par-client.

Migrer SAML → OIDC (côté IdP client)

Côté client : son admin IAM crée une nouvelle app OIDC dans son IdP, vous communique le client_id et le discovery URL, et bascule. La migration est instantanée — les sessions actives ne sont pas impactées, seules les nouvelles authentifications passent par le nouveau protocole.

Garder SAML pour certains tenants à long terme

C'est attendu et normal. Les grands comptes finance et secteur public ne migrent pas leurs IdP pour des raisons internes (audits IAM, processus de change management, certifications). Un éditeur SaaS qui retire SAML perd ces tenants.

Architecture Platform supporte OIDC sur tous les plans (Free, Pro, Enterprise) et SAML sur le plan Enterprise. Le choix architectural :

• OIDC par défaut via Keycloak self-hosted comme IdP du SaaS. Les tenants se connectent à leur propre IdP (Entra, Okta, Google) configuré comme identity broker dans Keycloak.
• Multi-tenant SSO par sous-domaine (Pattern 1) + email domain detection (Pattern 2) en fallback sur le login page principal.
• SAML add-on Enterprise car la configuration SAML demande plus de support technique (échange de metadata XML, debug XMLDSig). Le coût Enterprise reflète ce support.
• Audit log SSO systématique : chaque login, refresh, logout est tracé avec le tenant_id et le protocol utilisé. Exigence courante en audit RSSI.