SAML et OpenID Connect permettent tous deux l’authentification unique (SSO), mais ils ont été conçus pour des architectures différentes. Si vous choisissez le mauvais protocole d’authentification, vous serez confronté à une analyse XML complexe, à des problèmes de rotation des certificats ou à des lacunes en matière d’intégration mobile.

SAML 2.0 (standard OASIS, 2005) a été conçu pour la fédération des identités d’entreprise basée sur XML. Les applications web traditionnelles qui se connectent aux IdP d’entreprise en sont des exemples typiques. OpenID Connect (OpenID Foundation, 2014) étend OAuth 2.0 avec une couche d’authentification JSON légère optimisée pour les API, les applications mobiles et les architectures web modernes. Le choix dépend de votre plateforme cible et de ce qui existe déjà dans votre pile d’identité.

Exemple : votre entreprise a acquis une startup. L’application React de la startup doit prendre en charge à la fois les utilisateurs grand public qui s’authentifient auprès de Google (OIDC) et les employés de votre entreprise qui s’authentifient auprès du fournisseur d’identité de l’entreprise (SAML). Un IdP gère les deux protocoles, de sorte que votre application React conserve un point d’intégration unique, plutôt que d’implémenter des flux OIDC et SAML distincts.

Aspect	SAML 2.0	OpenID Connect (OIDC)
Objectif principal	Fédération d’entreprise	Authentification moderne avec OAuth 2.0
Format des données	Assertions XML avec signatures numériques	JSON Web Tokens (JWT) pour les tokens d’identification
Base	Protocole d’authentification et de fédération basé sur XML	Couche d’authentification fonctionnant par-dessus OAuth 2.0
Transport	Principalement HTTP-POST et HTTP-Redirect (profil SSO du navigateur)	HTTPS avec des redirections sur le canal frontal et des appels directs de token ou d’endpoint UserInfo
Configuration	Échange de métadonnées XML, gestion des certificats	Inscription du client via des documents de découverte (.well-known/openid-configuration)
Format de token	XML signé (et éventuellement crypté)	JWT pour les tokens d’identification ; les tokens d’accès sont spécifiques à l’implémentation (bien qu’OAuth 2.0/OIDC n’impose pas les tokens d’accès JWT, ils sont de plus en plus courants)
Usage recommandé	Environnements avec des exigences de fédération héritées pour le secteur public ou les secteurs réglementés	Applications monopages, applications mobiles, microservices, authentification sociale
Complexité de l’intégration	Plus complexe : analyse XML, gestion des métadonnées, rotation des certificats	Généralement moins complexe : analyse JSON, appels HTTP simples, configuration détectable

Différences pertinentes : les assertions SAML peuvent contenir des hiérarchies d’attributs riches pour répondre aux besoins complexes des entreprises. OIDC utilise des champs d’application (openid, profil, e‑mail) pour demander des revendications spécifiques dans le token d’identification et, éventuellement, via l’endpoint UserInfo.

SAML fonctionne indépendamment d’OAuth 2.0. OIDC superpose l’authentification aux flux d’autorisation OAuth 2.0, ce qui permet de disposer d’une pile de protocoles unifiée pour l’authentification et l’autorisation.

SAML (flux initié par le fournisseur de services) : votre fournisseur de services redirige les utilisateurs vers l’IdP avec une demande d’authentification AuthnRequest. L’IdP les authentifie, génère une assertion signée contenant les attributs utilisateurs et la renvoie au composant ACS (Assertion Consumer Service) via HTTP-POST. Vous validez la signature et les conditions de l’assertion, puis vous accordez l’accès. Ce flux implique généralement de multiples redirections du navigateur et une charge de traitement XML.

OIDC (flux de code d’autorisation avec PKCE) : votre application redirige les utilisateurs vers l’endpoint d’autorisation de l’IdP avec les champs d’application requis et une demande de code PKCE. Après authentification et consentement, l’IdP renvoie un code d’autorisation. Vous échangez ce code (ainsi que le vérificateur PKCE) contre un token d’identification et un token d’accès, et pouvez recevoir un token d’actualisation, en fonction du type de client et de la politique de l’IdP. Validez la signature du JWT, vérifiez les revendications (iss, aud, exp), et vous avez terminé. Ce flux est généralement plus simple à implémenter en raison de la prise en charge native de JSON/JWT dans les plateformes modernes.

Faites correspondre votre architecture au protocole approprié :

Choisissez SAML dans les cas suivants :

• Intégration avec les IdP d’entreprise existants
• Conception pour le secteur public ou des secteurs réglementés nécessitant une conformité FISMA, FedRAMP ou une fédération SAML héritée
• Travail avec des systèmes qui utilisent déjà SAML, lorsque les coûts de changement sont supérieurs aux avantages
• Traitement des exigences complexes en matière d’attributs utilisateurs (hiérarchies organisationnelles imbriquées, revendications personnalisées)

Choisissez OIDC dans les cas suivants :

• Création d’applications monopages (React, Vue, Angular) ou d’applications mobiles (iOS, Android)
• Ajout de fournisseurs d’authentification sociale (Google, GitHub, Apple)
• Création d’architectures API-first ou de microservices nécessitant des tokens d’accès OAuth 2.0
• Nouveau départ sans contraintes héritées, où l’installation plus simple d’OIDC réduit le temps de mise en production
• Priorité à l’expérience des développeurs avec de meilleures bibliothèques et une meilleure documentation

Et si vous avez besoin des deux ? Les IdP peuvent gérer la médiation des protocoles. L’application utilise OIDC lorsqu’elle se connecte à des IdP d’entreprise basés sur SAML. Vous n’avez pas à gérer deux implémentations de protocole.

Validation des tokens

• Pour OIDC : vérification des signatures JWT à l’aide du JWKS (JSON Web Key Set) publié par l’IdP, vérification de l’expiration (exp), vérification que l’audience (aud) correspond à votre ID client et confirmation que l’émetteur (iss) correspond à votre IdP.
• Pour SAML : vérification des signatures XML, vérification des conditions d’expiration (NotBefore, NotOnOrAfter) et validation des restrictions de l’audience.

Configuration du client

N’incorporez jamais les secrets clients dans les applications monopages ou mobiles : ils sont visibles dans les outils de développement de navigateur et les fichiers binaires d’applications. Utilisez PKCE (Proof Key for Code Exchange) pour le flux de code d’autorisation. PKCE protège contre l’interception du code d’autorisation sans nécessiter de secret, ce qui est obligatoire pour les clients publics (RFC 7636).

Gestion des sessions

OIDC hérite de la prise en charge des tokens d’actualisation d’OAuth 2.0 pour les sessions de longue durée. Échangez le token d’actualisation contre de nouveaux tokens d’accès lorsqu’ils expirent, à condition que votre IdP émette des tokens d’actualisation et que la configuration du client le permette. SAML s’appuie sur des sessions gérées par l’IdP et le fournisseur de services plutôt que sur un mécanisme de rafraîchissement standardisé, et prend en charge la déconnexion unique optionnelle (SLO), dont l’implémentation diffère d’un IdP à l’autre et peut s’avérer difficile à standardiser.

Gestion des erreurs

Enregistrez les échecs d’authentification avec le contexte (horodatage, codes d’erreur, identifiants du client, réponses de l’IdP) pour le débogage. Montrez aux utilisateurs des messages génériques de type « échec de l’authentification ». Évitez d’exposer les détails des tokens, les erreurs de revendications ou les défaillances de signature qui pourraient aider les attaquants.

OpenID Connect remplace-t-il SAML ?

Non, ils coexistent. L’adoption d’OIDC augmente rapidement pour les applications grand public et le développement mobile, car il repose sur OAuth 2.0. Cependant, SAML reste la norme dans les entreprises et le secteur public en raison des investissements existants dans l’infrastructure et de certaines exigences de conformité (FISMA, FedRAMP). La plupart des organisations utilisent les deux protocoles : OIDC pour les nouvelles applications, SAML pour la fédération d’entreprise.

Quel protocole est le plus sécurisé ?

Tous deux offrent une sécurité performante lorsqu’ils sont correctement implémentés. SAML utilise des signatures XML et un chiffrement optionnel ; OIDC utilise des signatures JWT et HTTPS. La différence essentielle : l’extension PKCE d’OIDC (RFC 7636) sécurise les clients publics, tels que les applications mobiles et monopages, où les secrets clients ne peuvent pas être protégés. SAML permet d’obtenir des protections similaires en utilisant la liaison d’artefacts ou les assertions du détenteur de la clé, mais ces modèles sont moins courants dans le développement d’applications modernes. La sécurité dépend de l’implémentation, et non du protocole choisi.

Pourquoi les applications mobiles préfèrent-elles OIDC à SAML ?

Le flux de code d’autorisation avec PKCE d’OIDC a été conçu pour les clients publics, comme les applications mobiles, qui ne peuvent pas stocker de manière sécurisée les secrets clients. Les tokens JSON d’OIDC s’intègrent nativement aux SDK mobiles, tandis que SAML nécessite des bibliothèques de traitement XML. OIDC prend en charge les schémas URI personnalisés (iOS) et les App Links (Android) pour une authentification transparente. Les principaux fournisseurs prennent majoritairement en charge les flux basés sur OIDC pour l’authentification mobile.

Quel est le meilleur parcours de migration de SAML à OIDC ?

Migrer de manière incrémentale, c’est-à-dire implémenter OIDC pour les nouvelles applications, tout en maintenant les intégrations SAML existantes. Utilisez une plateforme d’identité qui prend en charge la médiation de protocole afin que vos applications utilisent OIDC tout en se connectant à des IdP d’entreprise basés sur SAML. Cette stratégie permet de minimiser les risques sans perturber les relations existantes entre les fédérations. De nombreuses entreprises maintiennent des environnements hybrides pendant les phases de transition. Utilisez une plateforme d’identité qui gère la médiation du protocole, ce qui permet aux applications d’utiliser OIDC tandis que la plateforme gère la fédération SAML.

Quelle est la différence entre OAuth 2.0 et OIDC ?

OAuth 2.0 gère l’autorisation (accès aux API) par le biais de tokens d’accès. OIDC ajoute l’authentification (vérification de l’identité de l’utilisateur) par le biais de tokens d’identification basés sur OAuth 2.0. Lorsque vous implémentez la fonctionnalité « Se connecter avec Google », vous utilisez OIDC pour l’authentification et OAuth 2.0 pour l’accès aux API. OIDC étend OAuth 2.0 avec des revendications d’identité standardisées et l’endpoint UserInfo.

Le choix entre SAML et OIDC est essentiel pour sécuriser votre architecture d’authentification. Ces deux protocoles nécessitent une implémentation minutieuse, notamment en ce qui concerne la validation correcte des tokens, la gestion des certificats et le traitement des sessions. L’implémentation et le maintien des deux protocoles constituent un processus complexe.

Auth0 prend en charge à la fois SAML et OIDC, gère la médiation du protocole et met en œuvre les bonnes pratiques de sécurité afin que les développeurs puissent se concentrer sur les fonctionnalités de l’application.

Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.