SAML 2.0 : à quoi sert le protocole d’authentification ?

Pour une Direction des Systèmes d’Information (DSI), SAML 2.0 répond à une question concrète : comment donner à un collaborateur l’accès à des dizaines d’applications avec une seule authentification, tout en centralisant les politiques d’authentification auprès d’un fournisseur d’identité.

Qu’est-ce que SAML 2.0 ?

Cette centralisation de l’authentification, c’est précisément ce que normalise SAML. Le standard a été approuvé dans sa version 2.0 par l’OASIS (Organization for the Advancement of Structured Information Standards) en mars 2005, au plus haut niveau de ratification, en unifiant trois travaux antérieurs : SAML 1.1, le profil Liberty Alliance ID-FF 1.2 et les contributions du projet Shibboleth. Il a également été repris comme recommandation internationale par l’Union internationale des télécommunications (ITU-T X.1141).

Techniquement, le protocole SAML repose sur des assertions : des jetons de sécurité au format XML qui décrivent un utilisateur (le “principal”) et son authentification. Ces assertions sont échangées entre deux rôles :

• le fournisseur d’identité (Identity Provider, ou IdP), qui authentifie l’utilisateur ;
• le fournisseur de service (Service Provider, ou SP), c’est-à-dire l’application à laquelle l’utilisateur veut accéder.

Plus de vingt ans après sa ratification, SAML 2.0 n’est pas un protocole hérité : il reste largement déployé dans l’entreprise, le secteur public et le monde académique, où il constitue toujours un socle de la fédération d’identités.

Comment fonctionne l’authentification SAML ?

L’authentification SAML fait intervenir trois acteurs : l’utilisateur, le fournisseur d’identité (IdP) et le fournisseur de service (SP). Dans le scénario le plus courant, dit “initié par le fournisseur de service”, l’échange se déroule ainsi :

La confiance entre l’IdP et le SP ne s’improvise pas : elle est établie au préalable par un échange de métadonnées (certificats, points d’accès, identifiants), qui permet à chaque partie de vérifier l’authenticité des messages de l’autre. C’est la signature cryptographique de l’assertion qui garantit qu’elle provient bien du fournisseur d’identité attendu et n’a pas été altérée.

Les composants du standard SAML 2.0

Le standard SAML 2.0 s’organise en plusieurs briques normatives complémentaires :

• Les assertions : les énoncés eux-mêmes, qui peuvent porter trois types d’information : l’authentification, les attributs (rôle, service, adresse e-mail…) et, plus rarement utilisée, la décision d’autorisation.
• Les protocoles : les messages de requête et de réponse qui transportent les assertions.
• Les liaisons (bindings) : la manière dont ces messages circulent sur le web, par exemple via une redirection HTTP ou un envoi HTTP POST.
• Les profils : les combinaisons prêtes à l’emploi pour un usage donné, dont le plus connu est le profil d’authentification unique par navigateur web (Web Browser SSO Profile).
• Les métadonnées : la description technique échangée entre IdP et SP pour établir la confiance.

À noter : bien que SAML puisse transporter des décisions d’autorisation, son usage dominant reste l’authentification unique et le transport d’attributs. L’autorisation fine est le plus souvent gérée par d’autres mécanismes.

SAML 2.0, OAuth 2.0 et OpenID Connect : quelles différences ?

Ces trois standards sont souvent confondus alors qu’ils ne répondent pas à la même question :

• SAML 2.0 traite de l’authentification et de l’authentification unique. Fondé sur XML, il est très implanté dans les environnements d’entreprise, la fédération inter-organisations et le secteur public.
• OAuth 2.0 traite de l’autorisation : il délègue un accès à une ressource (“cette application peut-elle lire mon agenda ?”) et ne gère pas, à lui seul, l’authentification.
• OpenID Connect (OIDC) ajoute à OAuth 2.0 une couche d’authentification qui permet à une application d’établir l’identité de l’utilisateur, notamment grâce à un jeton d’identité (ID token) au format JWT. Il est adapté aux applications web et mobiles ; l’accès aux API s’appuie, quant à lui, sur les jetons d’accès d’OAuth 2.0.

En pratique, SAML 2.0 et OpenID Connect coexistent : le premier reste la référence pour l’existant applicatif d’entreprise, le second pour les nouveaux développements.

Mettre en œuvre SAML 2.0 avec Keycloak

Pour déployer SAML 2.0 sans réimplémenter le protocole, la voie la plus courante est de s’appuyer sur une solution de gestion des identités et des accès (Identity and Access Management, ou IAM). Keycloak, logiciel open source de référence dans ce domaine, peut agir comme fournisseur d’identité SAML 2.0 et prend aussi en charge OpenID Connect, ce qui permet de faire cohabiter applications historiques en SAML et développements récents en OIDC derrière un même point d’authentification.

Clever Cloud propose Keycloak as a Service, une offre de Keycloak infogéré et hébergé en France, opérée avec l’expertise de Please Open It, partenaire spécialiste de Keycloak. Cette approche décharge les équipes de l’exploitation du serveur d’identité (mises à jour, disponibilité, sauvegardes) tout en conservant le contrôle des réglages SAML et OIDC.

“SAML 2.0 reste incontournable en entreprise en raison de son ancienneté (2005), mais aussi de sa simplicité réseau : tout passe par le navigateur de l’utilisateur, sans besoin de connexion directe entre l’application et le serveur d’identité. De son côté, le standard moderne OpenID Connect impose une communication directe de serveur à serveur pour être sécurisé : le mode “100 % navigateur” d’OIDC (le flux Implicit) étant désormais abandonné car jugé trop vulnérable.”

Mathieu Passenaud
Co-fondateur chez Please Open It

FAQ

SAML 2.0 est-il toujours utilisé en 2026 ?

Oui. Ratifié en 2005, SAML 2.0 reste largement déployé dans l’entreprise, le secteur public et le monde académique pour l’authentification unique et la fédération d’identités. Il coexiste avec OpenID Connect, souvent privilégié pour les nouveaux projets web et mobiles.

Quelle est la différence entre SAML et le SSO ?

Le SSO (Single Sign-On, ou authentification unique) est un principe : s’authentifier une fois pour accéder à plusieurs applications. SAML est l’un des protocoles qui permettent de réaliser ce principe entre domaines ; OpenID Connect en est un autre.

SAML gère-t-il l’authentification ou l’autorisation ?

Les deux sont possibles, mais son usage dominant est l’authentification unique et le transport d’attributs. Le protocole peut porter des décisions d’autorisation, cette capacité étant toutefois rarement utilisée en pratique.

Faut-il choisir SAML 2.0 ou OpenID Connect ?

Cela dépend avant tout du protocole pris en charge par l’application. SAML 2.0 convient aux services qui attendent une fédération SAML ; OpenID Connect est généralement adapté à l’authentification des applications web et mobiles. Pour contrôler l’accès aux API, on utilise les jetons d’accès d’OAuth 2.0. Les deux approches peuvent coexister derrière un même fournisseur d’identité, comme Keycloak.

Keycloak prend-il en charge SAML 2.0 ?

Oui. Keycloak peut agir comme fournisseur d’identité SAML 2.0 et prend également en charge OpenID Connect, ce qui permet de faire cohabiter les deux protocoles.