SAML est un protocole d’authentification et de fédération qui offre une authentification unique (SSO) d’entreprise. OAuth 2.0 est un framework d’autorisation qui permet de déléguer l’accès à des API à l’aide de tokens d’accès.

L’authentification et l’autorisation sont les fondements de la gestion des identités et des accès (IAM). Toutefois, les protocoles sous-jacents de ces deux mécanismes (comme SAML et OAuth 2.0) ont des objectifs différents, bien que liés. Les confondre crée des failles de sécurité et des risques architecturaux inutiles.

Exemple : votre entreprise utilise Salesforce, Slack et un portail RH interne. Avec SAML, vous vous connectez une fois à votre annuaire d’entreprise et vous êtes immédiatement authentifié pour les trois outils (SSO d’entreprise). Lorsque vous souhaitez permettre à un outil d’analyse tiers d’accéder à vos données Salesforce sans partager votre mot de passe, vous utilisez OAuth 2.0, qui offre une autorisation déléguée à des ressources spécifiques.

SAML 2.0 :

• Authentifie les utilisateurs et offre un SSO d’entreprise
• Répond à la question « qui est cet utilisateur ? »
• Utilise des assertions XML avec des attributs d’identité
• Idéal pour : la fédération d’entreprise, le SSO des collaborateurs

OAuth 2.0 :

• Autorise l’accès aux ressources sans partager d’identifiants
• Répond à la question « à quoi cet utilisateur peut-il accéder ? »
• Émet des tokens d’accès (et éventuellement des tokens d’actualisation) pour les autorisations d’accès aux API
• Idéal pour : la sécurité des API, les applications mobiles, les accès tiers

OpenID Connect (OIDC) est une couche d’identités basée sur OAuth 2.0 qui prend en charge l’authentification via des tokens d’identification.

Bien que les deux soient des standards ouverts, leurs objectifs diffèrent. SAML 2.0 se concentre sur l’authentification et le SSO, en répondant à la question « qui est cet utilisateur ? ». À l’inverse, OAuth 2.0 se concentre sur l’autorisation, en répondant à la question « à quoi cet utilisateur peut-il accéder ? ».

SAML est conçu pour la fédération des identités dans les entreprises et les organismes publics. OAuth 2.0 est un framework d’autorisation conçu pour l’accès délégué, souvent utilisé pour sécuriser des API modernes et des applications grand public.

• SAML 2.0 (standard OASIS, 2005)
• OAuth 2.0 (RFC 6749 de l’IETF, 2012)
• OpenID Connect (OpenID Foundation, 2014)

Aspect	SAML 2.0	OAuth 2.0
Objectif principal	Authentification et SSO d’entreprise	Autorisation et accès délégué
Format des données	XML (assertions de sécurité)	OAuth 2.0 est indépendant du format des tokens ; la plupart des implémentations utilisent des JWT, bien que les tokens opaques soient également pris en charge
Artefacts clés	Assertions XML signées, métadonnées de fédération (hors bande)	Tokens d’accès, champs d’application
Transfert d’identité	Intégré : les assertions transportent explicitement des attributs d’identité (par exemple le rôle et l’adresse e-mail)	Non intégré : les tokens d’accès prouvent uniquement l’autorisation ; OpenID Connect ajoute les revendications d’identité
Adoption	Identité collaborateurs d’entreprise, systèmes hérités	API, applications mobiles/natives, microservices
Complexité des tokens	Élevée (analyse XML, signatures numériques)	Modérée (les JWT nécessitent la validation des signatures, des revendications et du cycle de vie des clés ; les tokens opaques nécessitent une introspection)

SAML utilise XML pour ses assertions de sécurité. XML accroît la charge de travail pour l’analyse et la validation des signatures, ce qui se traduit par des messages plus volumineux qui peuvent affecter les performances dans les environnements à haut débit.

OAuth 2.0 ne définit pas le format des tokens. Les JWT (JSON Web Token) sont courants, mais pas obligatoires. Compacts et légers, les JWT sont généralement validés par la vérification des signatures, la validation des revendications et la rotation des clés. Ils sont donc idéaux pour les applications mobiles et pour l’évolutivité de l’autorisation d’accès aux API. Si des tokens opaques sont utilisés, la validation est effectuée via l’introspection des tokens au lieu des vérifications locales des signatures.

La distinction essentielle réside dans ce que prouve l’artefact principal de chaque protocole.

Les assertions SAML sont une déclaration directe de l’identité et des attributs d’un utilisateur, émis par un fournisseur d’identité. Une application peut se fier à l’assertion pour confirmer l’identité de l’utilisateur et les groupes auxquels il appartient.

Les tokens d’accès OAuth 2.0 ne prouvent que l’autorisation d’accéder à une ressource spécifique. Le token n’est pas une preuve d’identité. L’utilisation d’OAuth 2.0 seul pour l’authentification, sans extension comme OIDC, crée une faille de sécurité, car le token d’accès ne vérifie pas l’identité de l’utilisateur.

Les protocoles diffèrent fondamentalement dans leurs flux :

• SAML met l’accent sur la confiance préétablie par l’échange de métadonnées et renvoie les données d’identité directement dans des assertions XML signées via des redirections de navigateur.
• OAuth 2.0 utilise des codes d’autorisation en tant qu’étape intermédiaire, le client échangeant des codes contre des tokens au niveau d’un endpoint backend, afin de permettre la distribution sécurisée de tokens sans les exposer dans le navigateur.

Utilisez SAML dans les cas suivants :

Exigences du SSO d’entreprise

• Gestion des identités centralisée
• SSO fluide pour plusieurs applications métier
• Échange d’attributs utilisateurs riches (service, rôle, groupes)

Conformité réglementaire

• Déclarations d’attributs intégrées pour l’auditabilité et la gouvernance
• Partage explicite de données d’identité pour le reporting de conformité

Fédération des grandes entreprises et des organismes publics
SAML est largement utilisé pour la fédération des identités des grandes entreprises et des organismes publics, y compris les plateformes d’entreprise modernes et les systèmes hérités. Les plateformes d’identité des grandes entreprises et des organismes publics prennent généralement en charge SAML en OIDC pour répondre aux différentes exigences en matière d’intégration.

Utilisez OAuth 2.0 dans les cas suivants :

Sécurité des API

• Protection des API REST en utilisant les champs d’application pour un contrôle granulaire des accès
• Autorisation sans état pour les microservices
• Sécurité des API par token

Applications mobiles et natives

• Format JSON léger et code d’autorisation avec PKCE (Proof Key for Code Exchange)
• Sécurisation des redirections basées sur navigateur en utilisant les navigateurs système plutôt que d’intégrer des vues web

Accès tiers

• Délégation d’autorisations spécifiques sans partage d’identifiants
• Authentification sociale (connexion avec Google ou Facebook)
• Accès avec champ d’application limité aux données utilisateurs

OIDC est une couche d’identités basée sur OAuth 2.0. Il introduit des tokens d’identification pour l’authentification des utilisateurs et standardise la façon dont les revendications d’identité sont représentées, tout en continuant à utiliser OAuth 2.0 pour émettre des tokens d’accès pour les autorisations d’accès aux API. OIDC ne remplace pas OAuth 2.0 ; il l’étend pour prendre en charge l’authentification et l’identité. Dans les flux modernes, OIDC gère l’authentification (émission de tokens d’identification), tandis qu’OAuth 2.0 gère l’autorisation (émission de tokens d’accès pour les appels d’API). Les deux travaillent généralement ensemble dans le même flux.

Fonctionnalités	OAuth 2.0	OIDC (extension d’OAuth 2.0)
Résultat principal	Token d’accès (autorisation)	Token d’identification (authentification)
Identité	Non (autorisation uniquement)	Oui (revendications d’identité, profil utilisateur)

1. Traitement d’OAuth 2.0 comme une authentification

• Les tokens d’accès OAuth 2.0 prouvent l’autorisation, pas l’identité.
• Utilisez OpenID Connect pour l’authentification ou mettez en place une vérification supplémentaire.

2. Validation inadéquate des tokens

• SAML : validation des signatures, vérification des conditions d’expiration (NotBefore/NotOnOrAfter), vérification des profils cibles
• OAuth 2.0 : validation de la signature, de l’expiration (exp), des profils cibles (aud), de l’émetteur (iss) et éventuellement de la revendication « not‑before » (nbf)
• La méthode de validation dépend du type de tokens : vérifiez le JWT localement ou utilisez l’introspection pour les tokens opaques.

3. Recours à des flux non sécurisés pour les clients publics

• Les applications natives ne peuvent pas stocker des secrets clients en toute sécurité (ce sont des clients « publics »).
• Utilisez le flux de type code d’autorisation avec PKCE pour les clients publics afin d’empêcher l’interception du code d’autorisation. (Les flux sans PKCE, tels que le flux de contrôle implicite, sont obsolètes et doivent être évités dans tout nouveau développement.)

Quelle est la principale différence entre SAML et OAuth 2.0 ?

SAML est utilisé pour l’authentification (déterminer l’identité de l’utilisateur), tandis qu’OAuth 2.0 est utilisé pour l’autorisation (déterminer ce à quoi l’utilisateur peut accéder). SAML est utilisé pour le SSO d’entreprise, tandis qu’OAuth 2.0 est utilisé pour le contrôle des accès aux API.

OAuth 2.0 peut-il remplacer SAML pour le SSO ?

OAuth 2.0 ne peut pas à lui seul remplacer SAML pour le SSO, car il s’agit strictement d’un framework d’autorisation. OIDC (basé sur OAuth 2.0) ajoute la couche d’authentification requise pour le SSO, mais contrairement à SAML, ses spécifications de déconnexion unique sont des extensions facultatives que les implémentations gèrent séparément.

Quel protocole est le plus sécurisé ?

Ces deux protocoles offrent de solides garanties de sécurité lorsqu’ils sont implémentés correctement. Les risques proviennent d’une implémentation défaillante, notamment d’une absence de validation des signatures, d’une gestion incorrecte des durées de vie des tokens, d’une faiblesse des contrôles des profils cibles et des émetteurs, ou d’une mauvaise configuration des endpoints d’autorisation. SAML offre des signatures au niveau du message et un chiffrement facultatif, tandis qu’OAuth 2.0, associé à PKCE et à une validation adaptée des tokens, offre une sécurité équivalente. Le choix du protocole doit privilégier l’adéquation architecturale plutôt que des hypothèses de sécurité.

Dois-je prendre en charge les deux protocoles ?

La plupart des applications n’ont pas besoin des deux en interne. Cependant, il se peut que vous deviez prendre en charge les deux lors de l’intégration avec des fournisseurs d’identité externes. Les entreprises clientes exigent souvent SAML, tandis que les applications grand public privilégient l’authentification sociale OAuth 2.0. Les plateformes d’identité gèrent la traduction des protocoles.

Pourquoi les API préfèrent-elles OAuth 2.0 à SAML ?

Les API préfèrent OAuth 2.0 parce que les tokens sont plus petits et plus faciles à analyser que les assertions XML, que l’autorisation basée sur le champ d’application est directement associée aux autorisations d’API, et que les langages de programmation modernes prennent mieux en charge les bibliothèques OAuth 2.0.

Le choix entre SAML et OAuth 2.0 dépend des exigences de votre application et de vos scénarios d’intégration. Les deux protocoles sécurisent la gestion des identités et des accès lorsqu’ils sont implémentés correctement.

L’utilisation d’une plateforme d’identité comme Auth0 élimine la complexité des protocoles en prenant en charge SAML, OAuth 2.0 et OpenID Connect. Votre application authentifie les utilisateurs par le biais d’une API cohérente, indépendamment du protocole sous-jacent. Explorez notre série d’articles « Introduction à l’IAM » pour approfondir vos connaissances sur les protocoles d’identité et les architectures d’authentification modernes.

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.