Se connecter une seule fois pour accéder à plusieurs applications est devenu un réflexe dans les entreprises. Derrière cette simplicité apparente, le protocole SAML 2.0 joue encore un rôle central dans de nombreux environnements professionnels, notamment pour le SSO, ou authentification unique.
Le protocole SAML 2.0, pour Security Assertion Markup Language, est un standard ouvert qui permet à un utilisateur de s’authentifier auprès d’un service, puis d’accéder à d’autres applications sans ressaisir ses identifiants. Il repose sur un principe simple : une entité de confiance confirme l’identité de l’utilisateur à une autre entité.
Dans un scénario de Single Sign-On, l’utilisateur ne se connecte pas directement à chaque application. Il est redirigé vers un système central d’authentification, souvent appelé fournisseur d’identité. Une fois l’identité validée, ce fournisseur transmet une preuve numérique à l’application demandée. Cette preuve prend la forme d’une assertion SAML, généralement encodée en XML.
Ce mécanisme est particulièrement répandu dans les organisations qui utilisent des solutions SaaS, des portails internes, des outils RH, des plateformes de collaboration ou des applications métiers. Il permet de centraliser les accès, de simplifier l’expérience utilisateur et de renforcer la gouvernance des identités.
Le fonctionnement de SAML 2.0 repose principalement sur deux acteurs. Le premier est le fournisseur d’identité, souvent abrégé IdP. Il s’agit du système chargé de vérifier l’identité de l’utilisateur. Il peut s’agir d’un annuaire d’entreprise, d’une plateforme IAM, d’Azure AD, d’Okta, de Keycloak ou d’une autre solution équivalente.
Le second acteur est le fournisseur de service, ou SP. Il correspond à l’application à laquelle l’utilisateur souhaite accéder. Cela peut être un CRM, un outil de gestion documentaire, une application de support, un intranet ou un service cloud. Le SP ne demande pas forcément le mot de passe de l’utilisateur : il fait confiance à l’IdP.
Cette séparation des rôles est essentielle. Elle évite de multiplier les bases de mots de passe dans chaque application et permet d’appliquer des règles cohérentes : authentification multifacteur, restrictions géographiques, politiques de session ou désactivation rapide d’un compte.
Dans le cas le plus courant, l’utilisateur commence par ouvrir une application compatible SAML. Le fournisseur de service constate qu’aucune session active n’existe et génère une requête d’authentification. Cette requête est ensuite envoyée au fournisseur d’identité, souvent via une redirection du navigateur.
L’IdP vérifie alors si l’utilisateur possède déjà une session active. Si ce n’est pas le cas, il lui demande de s’authentifier. Cette étape peut inclure un mot de passe, un code temporaire, une clé de sécurité ou une validation biométrique selon la politique définie par l’organisation. Une fois l’authentification réussie, l’IdP prépare une assertion SAML.
Cette assertion contient plusieurs éléments : l’identité de l’utilisateur, l’heure d’émission, la durée de validité, le destinataire prévu et parfois des attributs comme l’adresse e-mail, le nom, le rôle ou le groupe d’appartenance. Elle est généralement signée avec un certificat afin que le fournisseur de service puisse vérifier son authenticité.
Le navigateur transmet ensuite cette assertion au SP. Celui-ci vérifie la signature, contrôle que le message lui est bien destiné et s’assure que l’assertion n’a pas expiré. Si tout est conforme, l’application ouvre une session locale pour l’utilisateur. Le SSO SAML est alors effectif : l’accès est accordé sans nouvelle saisie d’identifiants.
Une assertion SAML est le cœur du protocole. Elle ne se contente pas de dire qu’un utilisateur est connecté ; elle fournit un ensemble d’informations structurées que le fournisseur de service peut interpréter. Le format XML peut sembler technique, mais sa logique est assez claire.
On y trouve d’abord un identifiant de sujet, appelé NameID. Il peut s’agir d’une adresse e-mail, d’un identifiant interne ou d’une valeur pseudonymisée. Ce choix dépend de la configuration entre l’IdP et le SP. Le but est d’identifier l’utilisateur de manière stable, sans forcément exposer plus de données que nécessaire.
L’assertion précise aussi les conditions d’utilisation. Elle peut indiquer une fenêtre temporelle très courte, l’audience autorisée ou encore l’application destinataire. Ces contrôles réduisent le risque de réutilisation frauduleuse. Dans certains contextes, l’assertion peut être chiffrée, mais la signature numérique reste le mécanisme de confiance principal.
Des attributs peuvent également être transmis pour automatiser l’accès. Par exemple, un groupe “finance” peut donner accès à un module comptable, tandis qu’un rôle “administrateur” peut activer des droits élargis. Cette approche facilite le provisionnement, mais elle exige une gestion rigoureuse des attributs et des groupes.
Malgré l’essor de protocoles plus récents comme OpenID Connect, SAML 2.0 demeure très présent dans les systèmes d’information. Sa popularité s’explique par sa maturité, sa compatibilité avec de nombreuses applications d’entreprise et son adoption historique dans les environnements B2B.
Le protocole répond bien aux besoins des organisations qui veulent centraliser l’authentification. Il limite la dispersion des identifiants, simplifie l’arrivée et le départ des collaborateurs, et rend les politiques de sécurité plus homogènes. Pour les équipes IT, le contrôle centralisé des accès représente un avantage opérationnel important.
SAML est aussi apprécié pour son interopérabilité. Les grandes plateformes cloud, les solutions RH, les outils de cybersécurité et les logiciels métiers proposent souvent une configuration SAML prête à l’emploi. Cette standardisation réduit les développements spécifiques, même si chaque intégration demande une attention particulière aux certificats, aux métadonnées et aux attributs.
Dans une démarche plus large de sécurité et de conformité, la gestion des identités s’articule avec la protection des informations personnelles ; le cadre de protection des données personnelles éclaire notamment les exigences liées au traitement et à la maîtrise des informations sensibles.
Un déploiement SAML efficace ne se limite pas à activer une option dans une interface d’administration. Le protocole repose sur la confiance entre l’IdP et le SP, ce qui impose une configuration précise. Une erreur de paramétrage peut affaiblir la sécurité du dispositif.
Le premier point concerne les certificats. Les assertions doivent être signées avec un certificat valide, connu du fournisseur de service. Lorsqu’un certificat expire ou est remplacé sans coordination, les connexions peuvent échouer. À l’inverse, accepter des signatures trop permissives peut exposer l’application à des risques d’usurpation.
La durée de validité des assertions doit aussi être courte. Une assertion valable trop longtemps augmente le risque de réutilisation en cas d’interception. Les paramètres comme l’audience, le destinataire et l’horodatage doivent être strictement vérifiés. Le chiffrement TLS reste indispensable pour protéger les échanges entre navigateur, IdP et SP.
La sécurité dépend également de l’infrastructure qui soutient l’authentification. La résolution des noms de domaine doit être fiable, car une redirection vers un mauvais service peut compromettre la chaîne de confiance ; la sécurisation de la résolution DNS participe ainsi à la protection globale des accès.
SAML est souvent comparé à OAuth 2.0 et OpenID Connect, mais ces technologies ne répondent pas exactement aux mêmes besoins. SAML 2.0 sert principalement à transmettre une preuve d’authentification entre un fournisseur d’identité et une application. Il est très utilisé pour le SSO d’entreprise.
OAuth 2.0, lui, est d’abord un protocole d’autorisation. Il permet à une application d’accéder à une ressource au nom d’un utilisateur, sans connaître son mot de passe. OpenID Connect ajoute une couche d’authentification au-dessus d’OAuth 2.0 et s’est imposé dans de nombreux usages web et mobiles.
En pratique, SAML reste fréquent pour les applications professionnelles historiques ou SaaS orientées entreprise, tandis qu’OpenID Connect est souvent privilégié pour les architectures modernes, les API et les applications mobiles. Le choix dépend du contexte, des solutions déjà en place et des exigences d’intégration.
Le protocole SAML 2.0 permet de mettre en place une authentification unique fiable entre un fournisseur d’identité et plusieurs applications. Son fonctionnement repose sur l’échange d’assertions signées, qui prouvent l’identité de l’utilisateur sans transmettre directement ses identifiants à chaque service.
Bien configuré, le protocole SAML 2.0 améliore l’expérience utilisateur, réduit la gestion dispersée des mots de passe et renforce le pilotage des accès. Il demande toutefois une attention particulière aux certificats, aux attributs, aux durées de validité et aux règles de confiance entre systèmes.
Dans un environnement où les applications cloud et les identités numériques se multiplient, SAML conserve une place solide. Il n’est pas toujours le protocole le plus récent, mais il reste un standard robuste pour organiser le SSO sécurisé dans de nombreuses entreprises.
