SAML vs OIDC : quel protocole d’authentification unique ?

SAML vs OIDC, c’est le choix de protocole qui sous-tend l’authentification unique (SSO). Avec SAML 2.0 (norme OASIS, mars 2005), un fournisseur d’identité signe une assertion XML concernant l’utilisateur, que le navigateur transmet au fournisseur de services. OpenID Connect (Core 1.0, février 2014, également ISO/IEC 26131:2024) ajoute une couche d’identité à OAuth 2.0 : le fournisseur émet un JWT signé, le jeton d’ID, généralement via le flux de code d’autorisation, et peut émettre dans le même échange des jetons d’accès pour des API.

Vue d’ensemble

Comment chacun connecte un utilisateur

En SAML, le fournisseur de services redirige le navigateur vers le fournisseur d’identité avec une requête AuthnRequest. Une fois l’utilisateur connecté, l’IdP renvoie un formulaire HTML qui envoie par POST une réponse Response encodée en base64 contenant l’assertion : émetteur, sujet, restriction d’audience, période de validité, attributs et une signature XML. Le fournisseur de services vérifie la signature avec le certificat issu des métadonnées de l’IdP et contrôle les conditions.

En OpenID Connect, le client redirige vers le point de terminaison d’autorisation du fournisseur avec scope=openid, un state, un nonce et un challenge PKCE. Le fournisseur renvoie un code à usage unique à l’URI de redirection ; le client l’échange auprès du point de terminaison de jeton contre le jeton d’ID et le jeton d’accès, sur une connexion TLS directe, si bien que les jetons ne passent jamais par la barre d’adresse du navigateur.

Le script ci-dessous lit les deux types de configuration auprès du même fournisseur (20 octobre 2026, curl et jq 1.8.1). D’une requête à l’autre, la taille des métadonnées SAML a varié entre 28 et 32 Ko et le JWKS entre 7 et 8 clés, selon le serveur qui répondait.

#!/bin/sh
base=https://login.microsoftonline.com/common
echo "== OpenID Connect discovery"
curl -s "$base/v2.0/.well-known/openid-configuration" -o oidc.json
echo "bytes: $(wc -c < oidc.json | tr -d ' ')"
jq -c '{id_token_signing_alg_values_supported, response_types_supported}' oidc.json
curl -s "$(jq -r .jwks_uri oidc.json)" | jq -c '{jwks_keys: (.keys | length), kty: ([.keys[].kty] | unique)}'

echo "== SAML 2.0 metadata"
curl -s "$base/FederationMetadata/2007-06/FederationMetadata.xml" -o saml.xml
echo "bytes: $(wc -c < saml.xml | tr -d ' ')"
grep -o 'SignatureMethod Algorithm="[^"]*"' saml.xml | sort -u
grep -o 'SingleSignOnService Binding="[^"]*"' saml.xml | sort -u
echo "distinct certificates: $(grep -o '<X509Certificate>[^<]*' saml.xml | sort -u | wc -l | tr -d ' ')"
rm -f oidc.json saml.xml

== OpenID Connect discovery
bytes: 1728
{"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"]}
{"jwks_keys":7,"kty":["RSA"]}
== SAML 2.0 metadata
bytes: 28179
SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
distinct certificates: 5

Ce que doit vérifier une partie de confiance

SAML : vérifiez la signature XML avec le certificat de l’IdP que vous avez configuré (jamais avec un certificat intégré au message), et assurez-vous que la signature couvre exactement l’assertion que lit votre code ; vérifiez ensuite Issuer, Destination, InResponseTo, AudienceRestriction, NotBefore et NotOnOrAfter, et refusez les rejeux. La difficulté est structurelle. XML Signature signe des éléments référencés par leur ID après canonicalisation, si bien qu’un document peut contenir un élément valablement signé et un autre élément, différent et non signé, que l’application traite à sa place. En 2012, Somorovsky et ses collègues ont mis en évidence ce type de signature wrapping dans 11 frameworks SAML sur 14 ; en 2024 et 2025, ruby-saml (utilisé par GitLab) a de nouveau dû être corrigé (CVE-2024-45409, CVE-2025-25291 et CVE-2025-25292), parce que deux analyseurs XML de la même bibliothèque lisaient différemment un même document.

OpenID Connect (Core §3.1.3.7) : vérifiez le JWS avec une clé du JWKS du fournisseur, sélectionnée par kid, et avec l’algorithme que vous attendez ; vérifiez ensuite iss, aud (votre ID client), exp, iat et le nonce que vous avez envoyé. JSON n’a qu’un seul arbre d’analyse et la signature couvre exactement les octets reçus, il n’y a donc pas de problème de wrapping ; les écueils restants sont l’acceptation d’algorithmes inattendus, l’absence de vérification du claim aud et une correspondance laxiste des URI de redirection, que traitent les bonnes pratiques actuelles de sécurité d’OAuth (RFC 9700, janvier 2025). Le validateur de jetons OIDC effectue ces vérifications avec le JWKS en ligne d’un fournisseur, et l’inspecteur SAML montre quel élément une signature couvre réellement.

Quand choisir l’un ou l’autre

• Nouvelles applications, applications mobiles, applications monopages, API : OpenID Connect avec le flux de code et PKCE.
• Vente de SaaS aux entreprises : prenez en charge les deux ; chez de nombreux clients, les équipes chargées des identités configurent encore SAML en premier.
• Fédérations de recherche et d’enseignement (eduGAIN, InCommon) : SAML, avec des agrégats de métadonnées ; OpenID Federation 1.0 (version finale depuis février 2026) est en phase pilote pour eduGAIN, mais n’est pas encore la norme.
• Administrations et secteurs réglementés : suivez le profil qu’impose votre écosystème ; l’open banking et les régimes similaires utilisent FAPI 2.0, un profil renforcé d’OAuth et d’OpenID Connect.
• Provisionnement des utilisateurs et des groupes : ni l’un ni l’autre ; utilisez SCIM 2.0 (RFC 7643 et RFC 7644) en complément de l’un ou l’autre protocole.

Notes de migration

1. Faites fonctionner les deux en parallèle : configurez une application OIDC dans le même fournisseur d’identité et associez le même identifiant utilisateur (sub ou un attribut stable) aux comptes existants avant de basculer.
2. Associez les attributs aux claims de façon explicite ; les noms d’attributs SAML (souvent des URN) correspondent rarement aux noms de claims OIDC, et les claims de groupes peuvent nécessiter un appel d’API distinct lorsque les utilisateurs appartiennent à de nombreux groupes.
3. Utilisez une bibliothèque certifiée pour OpenID Connect, activez la découverte et la mise en cache du JWKS avec actualisation en cas de kid inconnu, et épinglez les algorithmes acceptés.
4. Renforcez ce qui reste en SAML : mettez à jour la bibliothèque, exigez des assertions signées, rejetez les documents qui contiennent plusieurs assertions ou des DTD, et surveillez l’expiration des certificats dans les métadonnées des partenaires.
5. Planifiez la déconnexion séparément : faites correspondre le Single Logout de SAML au Back-Channel Logout d’OIDC là où les sessions doivent prendre fin de façon centralisée.
6. Retirez la connexion SAML seulement lorsque les journaux n’ont enregistré aucune ouverture de session SAML pendant un cycle d’activité complet.

Références

• OASIS SAML 2.0 Core et Bindings
• OpenID Connect Core 1.0 (§3.1.3.7, validation du jeton d’ID)
• OpenID Connect Discovery 1.0
• OpenID Connect Back-Channel Logout 1.0
• RFC 9700, bonnes pratiques actuelles de sécurité pour OAuth 2.0
• RFC 7636, PKCE et RFC 8252, OAuth pour les applications natives
• W3C XML Signature 1.1, syntaxe et traitement
• Somorovsky et al., « On Breaking SAML », USENIX Security 2012