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

SAML, OpenID Connect et OAuth 2.0 reviennent dans tous les projets d’authentification unique (SSO). Ces trois protocoles sont souvent confondus, alors qu’ils ne répondent pas au même besoin. Comprendre la différence entre SAML et OpenID Connect, et la place d’OAuth 2.0, évite des choix d’architecture coûteux et des failles de sécurité.

Authentification ou autorisation : la distinction de départ

L’authentification répond à la question « qui êtes-vous ? ». L’autorisation répond à « qu’avez-vous le droit de faire ? ».

SAML et OpenID Connect servent à authentifier un utilisateur et à transmettre son identité à une application. OAuth 2.0, lui, sert à autoriser une application à accéder à des ressources au nom de l’utilisateur. Il ne dit rien, à lui seul, de l’identité de cet utilisateur.

SAML 2.0 : le standard historique du SSO en entreprise

Publié en 2005 par l’OASIS, SAML 2.0 fait circuler l’identité sous forme d’assertions XML signées. Le fournisseur d’identité (IdP), par exemple ADFS ou Microsoft Entra ID, authentifie l’utilisateur. Il transmet ensuite l’assertion au fournisseur de service (SP), c’est-à-dire l’application, via le navigateur.

SAML est mature et supporté par la quasi-totalité des applications SaaS d’entreprise. Son format XML est en revanche lourd, complexe à sécuriser et peu adapté aux applications mobiles et aux API.

OAuth 2.0 : déléguer un accès, pas prouver une identité

OAuth 2.0, normalisé par l’IETF en 2012, permet à une application d’obtenir un jeton d’accès (access token) limité à certains droits, appelés scopes. Exemple : une application de planning lit votre calendrier sans jamais connaître votre mot de passe.

C’est aujourd’hui le standard de fait pour sécuriser l’accès aux API. L’erreur classique consiste à l’utiliser seul pour « connecter » un utilisateur : un jeton d’accès prouve un droit d’accès, pas une identité.

OpenID Connect : l’identité au-dessus d’OAuth 2.0

OpenID Connect, publié en 2014 par l’OpenID Foundation, ajoute une couche d’identité à OAuth 2.0. En plus du jeton d’accès, l’application reçoit un jeton d’identité (ID token). Il contient l’identifiant de l’utilisateur, l’émetteur, la date et la méthode d’authentification.

Basé sur JSON et des échanges web simples, OpenID Connect convient aux applications web modernes, mobiles et aux API. Une adresse de découverte standard permet aussi de configurer automatiquement l’application.

Le comparatif en un tableau

Lequel choisir ?

• Application SaaS ou d’entreprise qui ne propose que SAML : SAML, tout simplement.
• Nouvelle application web, mobile ou monopage : OpenID Connect.
• Donner à une application l’accès à une API : OAuth 2.0, complété par OpenID Connect si l’application a aussi besoin de connaître l’utilisateur.

En pratique, vous n’avez pas à choisir un seul protocole. Les fournisseurs d’identité du marché (Microsoft Entra ID, Okta, Keycloak, ADFS) gèrent SAML et OpenID Connect en parallèle, application par application.

Les erreurs à éviter

• Utiliser un jeton d’accès OAuth comme preuve d’identité.
• Ne pas vérifier la signature, l’émetteur, le destinataire et la date d’expiration des jetons et des assertions.
• Conserver des flux OAuth obsolètes comme le flux implicite. Préférez le flux « code d’autorisation » avec PKCE.
• Oublier l’expiration des certificats de signature SAML. Un certificat expiré sur l’IdP coupe d’un coup l’accès à toutes les applications fédérées.