Dès qu’une application cesse de gérer elle-même les mots de passe pour déléguer la connexion à un tiers de confiance, elle parle l’un de ces quatre protocoles: OAuth 2.0, OpenID Connect, SAML 2.0 ou WS-Federation. On les confond souvent, parce qu’ils résolvent des variantes d’un même problème — faire confiance à un annuaire central sans jamais voir le secret de l’utilisateur — mais ils ne disent pas tous la même chose, ni à la même époque. Cet article les démonte un par un, avec leurs échanges, puis les met côte à côte.
Authentification et autorisation: ne pas confondre les deux questions
Tout part d’une distinction que ces protocoles traitent différemment. L’authentification répond à « qui es-tu? »; l’autorisation répond à « qu’as-tu le droit de faire? ». OAuth 2.0 ne répond qu’à la seconde: c’est un protocole de délégation d’accès, pas de preuve d’identité. OpenID Connect ajoute la première par-dessus OAuth. SAML et WS-Federation, eux, sont nés pour faire les deux d’un coup, au service du SSO web d’entreprise. Garder cette grille en tête évite l’erreur la plus courante, qui est d’utiliser OAuth seul pour « connecter » un utilisateur.
Un point commun à retenir avant d’entrer dans le détail: ces quatre protocoles s’appuient sur le navigateur et des redirections, pas sur un échange direct entre l’application et l’annuaire. L’étage en dessous — comment l’utilisateur prouve son identité à l’annuaire, par mot de passe, par passkey ou autre — est un autre sujet, indépendant du protocole de fédération choisi.
OAuth 2.0: déléguer l’accès
OAuth 2.0 (RFC 6749, 2012) répond à une question précise: comment une application peut-elle accéder à une ressource au nom de l’utilisateur, sans connaître son mot de passe? Il définit quatre rôles. Le propriétaire de la ressource est l’utilisateur. Le client est l’application qui veut accéder à quelque chose. Le serveur d’autorisation authentifie l’utilisateur et émet des jetons. Le serveur de ressources (l’API) héberge les données et accepte les jetons.
Le client reçoit un jeton d’accès, une chaîne qu’il présente à l’API à chaque requête, souvent accompagné d’un jeton de rafraîchissement pour en obtenir un nouveau sans redemander l’utilisateur. Les scopes délimitent ce que le jeton autorise (lire les mails, mais pas les envoyer, par exemple). Le jeton d’accès est opaque pour le client: il ne cherche pas à le lire, il le transmet.
Le flux canonique est le code d’autorisation avec PKCE. Le client prépare un secret éphémère (code_verifier) et son empreinte (code_challenge), redirige le navigateur vers le serveur d’autorisation, récupère un code à usage unique, puis l’échange en direct contre les jetons en prouvant qu’il détient bien le secret. PKCE lie le code à celui qui l’a demandé, ce qui ferme l’interception du code.
Flux « code d’autorisation + PKCE »: le code passe par le navigateur, l’échange contre les jetons se fait en direct.
D’autres flux existent pour d’autres besoins: client credentials pour une application qui agit en son nom propre, de machine à machine; device code pour un appareil sans clavier ni navigateur. En revanche deux anciens flux sont désormais écartés: le flux implicit (qui renvoyait le jeton directement dans l’URL) et le flux mot de passe (où le client voyait le mot de passe). La bonne pratique de sécurité OAuth, publiée en RFC 9700, les déconseille, et le brouillon OAuth 2.1 les retire en faisant de PKCE la règle pour tous.
OpenID Connect: l’identité par-dessus OAuth
OAuth a un angle mort: à la fin du flux, le client détient un jeton d’accès, mais il ne sait pas qui est l’utilisateur. Rien dans OAuth ne le lui dit de façon fiable. OpenID Connect (OIDC, 2014) comble ce vide en ajoutant une couche d’identité au-dessus d’OAuth 2.0, sans en changer les échanges.
Concrètement, le client ajoute le scope openid à sa demande. En plus du jeton d’accès, le serveur renvoie alors un jeton d’identité (ID token): un JWT signé, que le client est cette fois censé lire et valider. Il contient des revendications normalisées — l’émetteur (iss), le sujet (sub, l’identifiant stable de l’utilisateur), le destinataire (aud), l’expiration (exp), et le nonce qui lie le jeton à la demande. Un endpoint UserInfo fournit au besoin les attributs de profil, et un document de découverte publié sur /.well-known/openid-configuration décrit tous les endpoints et les options du fournisseur, ce qui évite de les configurer à la main.
Ce qu’OpenID Connect ajoute à OAuth: un jeton d’identité lisible, un endpoint de profil et la découverte.
La nuance est fondamentale: le jeton d’accès est fait pour l’API et reste opaque au client; le jeton d’identité est fait pour le client et lui dit qui vient de se connecter. C’est cette combinaison — OAuth pour l’accès, OIDC pour l’identité — qui équipe aujourd’hui la grande majorité des applications web, mobiles et monopages.
SAML 2.0: le vétéran du SSO web d’entreprise
SAML 2.0 (2005) est antérieur de sept ans à OAuth, et il vient d’un autre monde, celui du XML. Il définit deux rôles: le fournisseur d’identité (IdP), qui authentifie, et le fournisseur de service (SP), l’application. Entre les deux circulent des assertions, des documents XML signés qui affirment l’identité de l’utilisateur et portent ses attributs.
Le scénario habituel est initié par le SP. L’utilisateur arrive sur l’application, qui fabrique une AuthnRequest et renvoie le navigateur vers l’IdP (liaison HTTP-Redirect). L’IdP authentifie l’utilisateur, puis renvoie une Response contenant l’assertion signée, le plus souvent par un formulaire auto-soumis (liaison HTTP-POST). Le SP vérifie la signature XML, et ouvre la session. Un document de métadonnées XML, échangé à la configuration, fixe les URL, les certificats et les formats de part et d’autre.
SSO SAML initié par le SP: l’assertion signée transite par le navigateur en HTTP-POST.
SAML reste très présent dans le SaaS d’entreprise, où il est souvent la case à cocher attendue par les acheteurs. Sa déconnexion centralisée (Single Logout, SLO) et ses déclarations d’attributs détaillées répondent à des besoins réels, au prix d’une mise en œuvre plus lourde: tout est XML, signatures comprises.
WS-Federation: le monde Microsoft historique
WS-Federation (début des années 2000) vient de la famille WS-*, portée à l’époque par Microsoft et IBM. Fonctionnellement, il ressemble à SAML — un IdP, une application, un jeton signé transporté par le navigateur — mais avec sa propre grammaire. La demande se fait par une URL wsignin1.0 portant des paramètres comme wtrealm (l’identifiant de l’application), wreply (où revenir) et wctx (le contexte à reporter). Le jeton renvoyé est généralement une assertion SAML, souvent au format 1.1, enveloppée dans les structures WS-*. La déconnexion passe par wsignout1.0.
C’est le protocole d’ADFS, de SharePoint et de nombreuses applications .NET d’entreprise. On le croise encore dans ces environnements, mais on ne démarre plus de projet dessus: pour une intégration neuve, le choix se fait aujourd’hui entre SAML et OIDC. Il garde un intérêt pour relier une application héritée à un annuaire moderne, qui sait encore le parler.
La comparaison
Deux familles se dégagent. D’un côté le monde XML et WS-* (SAML, WS-Federation), conçu pour le SSO web d’entreprise de la décennie 2000. De l’autre le monde JSON et REST (OAuth, OIDC), conçu pour les API, le mobile et les applications monopages. Tous passent par le navigateur et des redirections; la vraie ligne de partage est l’âge, l’écosystème et le format des messages.
| Aspect | OAuth 2.0 | OpenID Connect | SAML 2.0 | WS-Federation |
|---|---|---|---|---|
| Rôle | Autorisation (accès) | Authentification (identité) | Authentification + SSO | Authentification + SSO |
| Format | JSON | JSON / JWT | XML | XML (WS-*) |
| Jeton | access + refresh (opaques) | id token (JWT signé) | assertion SAML (XML-DSig) | assertion SAML via WS-* |
| Découverte | metadata (RFC 8414) | /.well-known/openid-configuration | métadonnées XML | métadonnées XML |
| Apparu | 2012 | 2014 | 2005 | ~2003 |
| Terrain | API, délégation d’accès | web, mobile, SPA | SSO d’entreprise, SaaS | apps Microsoft héritées |
| Déconnexion | révocation de jeton | logout RP-initiated, front/back-channel | Single Logout (SLO) | wsignout1.0 |
Où on les croise, et lequel choisir
Un annuaire moderne comme Microsoft Entra ID parle les quatre. Une application enregistrée via les App registrations est en OIDC/OAuth par défaut; le SSO SAML et WS-Federation reste proposé pour les applications qui l’exigent. Le guide de décision de Microsoft est direct sur le choix: SAML est « un protocole de fédération mature basé sur XML », OIDC « un protocole de connexion moderne bâti sur OAuth 2.0 », et sa recommandation tient en une phrase — en cas de doute, OIDC par défaut pour tout nouveau développement.
En pratique: OIDC (avec OAuth pour l’accès aux API) pour toute application neuve, web, mobile ou monopage; SAML quand un client d’entreprise ou une contrainte de conformité l’impose; WS-Federation seulement pour maintenir l’existant côté ADFS ou SharePoint. Et quand la clientèle est mixte, les fournisseurs SaaS supportent souvent SAML et OIDC en parallèle.
Ces protocoles ne font qu’établir la confiance et transporter le verdict. Ce qu’ils transportent ensuite — le jeton de session, son cycle de vie, sa protection contre le vol — est une autre histoire, celle que nous avons suivie côté Entra avec le Primary Refresh Token. Choisir le bon dialecte de fédération, c’est la première brique; protéger les jetons qui en découlent, c’est la suivante.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.