OAuth 2.0, OpenID Connect, SAML : l'authentification unique (SSO)

L'authentification unique, ou SSO (Single Sign-On), permet à un utilisateur de s'authentifier une seule fois auprès d'un fournisseur d'identité pour accéder ensuite à plusieurs applications sans retaper son mot de passe. Trois protocoles la rendent possible sur le web : OAuth 2.0, qui délègue une autorisation d'accès à une API ; OpenID Connect, qui ajoute à OAuth 2.0 la preuve de l'identité de l'utilisateur ; et SAML 2.0, plus ancien, très présent dans les entreprises. Ce chapitre explique leurs rôles, le parcours d'une connexion et les erreurs d'intégration à éviter.

Ce que l'authentification unique change

Sans SSO, chaque application gère ses propres comptes : l'utilisateur jongle avec dix mots de passe, le service informatique désactive dix comptes au départ d'un salarié (et en oublie un). Avec le SSO, les applications délèguent l'authentification à un fournisseur d'identité (Identity Provider, IdP), qui vérifie le mot de passe et la MFA puis leur transmet une preuve signée.

Le vocabulaire

OAuth 2.0 : déléguer une autorisation, pas prouver une identité

OAuth 2.0 (RFC 6749) est un protocole d'autorisation déléguée. Il répond à cette question : comment permettre à une application d'accéder à des données d'un utilisateur, chez un autre service, sans lui donner le mot de passe de ce service ? Exemple : une application de planification veut lire l'agenda professionnel de Julie. Plutôt que de demander son mot de passe, elle la redirige vers le service d'agenda, où Julie consent ; l'application reçoit un jeton d'accès limité à la lecture de l'agenda.

Quatre rôles :

• le propriétaire de la ressource : Julie ;
• le client : l'application de planification ;
• le serveur d'autorisation : celui qui authentifie Julie, recueille son consentement et délivre les jetons ;
• le serveur de ressources : l'API de l'agenda, qui accepte le jeton d'accès.

Le jeton d'accès est limité par des portées (scopes), par exemple agenda.lecture, et par une durée de vie courte.

Le flux à retenir : le code d'autorisation avec PKCE

OAuth 2.0 définit plusieurs façons d'obtenir un jeton, les flux (grants). Les recommandations de sécurité publiées par l'IETF en janvier 2025 (RFC 9700) en écartent deux : le flux implicite (le jeton revenait dans l'URL) et le flux qui transmet le mot de passe de l'utilisateur au client. Pour un utilisateur, il reste le flux du code d'autorisation, protégé par PKCE (Proof Key for Code Exchange, RFC 7636), que le serveur d'autorisation doit prendre en charge pour tous les types de clients.

Le code passe par le navigateur ; les jetons, jamais (pour une application avec une partie serveur, le cas du schéma). Les étapes 1 et 3 sont des redirections : le navigateur porte la demande à l'IdP, puis rapporte le code à l'application. Les étapes 4 et 5 se font sur un canal direct entre l'application et l'IdP : un code intercepté ne suffit pas, il faut aussi le code_verifier, que seule l'application connaît.

Les paramètres de la première redirection ont chacun un rôle de sécurité :

Le PKCE se calcule ainsi : code_challenge = BASE64URL(SHA256(code_verifier)). Avec l'exemple de la RFC 7636, le vérificateur dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk donne le défi E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM. Seule l'application qui a généré le vérificateur peut échanger le code.

Pour les échanges entre machines, sans utilisateur (un script de synchronisation qui appelle une API), on utilise le flux des identifiants client (client credentials) : le service s'authentifie avec son propre identifiant et un secret ou un certificat.

OpenID Connect et l'ID token

OpenID Connect (OIDC) ajoute à OAuth 2.0 l'ID token, un JWT signé par le fournisseur d'identité qui décrit l'authentification :

{
  "iss": "https://sso.sorbier.example/realms/sorbier",
  "sub": "f3a1c9e2-5b7d-4c1e-9a0b-2d6e8f4a7c31",
  "aud": "outil-tickets",
  "exp": 1793607300,
  "iat": 1793607000,
  "nonce": "n-0S6_WzA2Mj",
  "auth_time": 1793606990,
  "amr": ["pwd", "otp"],
  "email": "chloe.lambert@sorbier.example",
  "name": "Chloé Lambert"
}

Avant de croire l'ID token, l'application vérifie :

1. la signature, avec la clé publique du fournisseur (publiée dans un document JWKS) ;
2. l'émetteur iss : c'est bien notre fournisseur d'identité ;
3. l'audience aud : le jeton a été émis pour cette application, pas pour une autre ;
4. l'expiration exp ;
5. le nonce, égal à celui qu'elle a envoyé.

Le fournisseur publie toute sa configuration (adresses des points d'accès, clés, algorithmes) à une adresse normalisée, /.well-known/openid-configuration : une bibliothèque OIDC s'y connecte et récupère tout automatiquement.

SAML 2.0

SAML 2.0 (Security Assertion Markup Language, 2005) fait la même chose qu'OIDC avec des assertions XML signées, transmises par le navigateur au moyen de redirections et de formulaires. Il reste très répandu pour les applications d'entreprise (logiciels RH, outils en ligne) et dans l'enseignement supérieur.

Dans un domaine Active Directory, les postes Windows bénéficient d'une autre forme d'authentification unique : le ticket Kerberos obtenu à l'ouverture de session donne accès aux partages, aux imprimantes et à l'intranet sans nouvelle saisie (chapitre 7). Les fournisseurs d'identité web comme Keycloak savent d'ailleurs s'appuyer sur l'annuaire et sur Kerberos.

Côté SISR : mettre en place un fournisseur d'identité

Antoine Mercier veut que les salariés de Sorbier Logistique accèdent à l'outil de tickets, à l'intranet et au wiki avec leur compte du domaine. Sa démarche :

1. Inventorier l'existant : quelles applications, quels comptes, quels rôles dans chacune. C'était tout le dossier A du sujet de 2024, qui faisait écrire une vue SQL rassemblant les comptes de plusieurs bases (une UNION : voir les vues SQL) et créer un compte de base de données aux droits strictement nécessaires pour le programme d'inventaire.
2. Installer le fournisseur d'identité, par exemple Keycloak (libre) dans un conteneur, en HTTPS avec un certificat valide, derrière le pare-feu.
3. Le relier à l'annuaire : Keycloak lit les comptes et les groupes de l'Active Directory en LDAPS, sans copier les mots de passe.
4. Déclarer chaque application comme client, avec son adresse de retour exacte, et associer les groupes de l'annuaire aux rôles de l'application.
5. Activer la MFA pour tous, et la rendre obligatoire pour les rôles sensibles.
6. Prévoir la disponibilité : deux instances, une sauvegarde de la configuration, une procédure si le fournisseur est indisponible.
7. Centraliser les journaux de connexion et alerter sur les anomalies.

Côté SLAM : intégrer OpenID Connect dans une application

Le développeur n'écrit pas le protocole : il utilise une bibliothèque certifiée (il en existe pour Node.js, PHP, Java, C# et Python) et configure trois choses : l'adresse du fournisseur, l'identifiant et le secret du client, l'adresse de retour. Le parcours dans l'application :

1. la route /connexion génère state, nonce et code_verifier, les garde dans la session et redirige vers le fournisseur ;
2. la route de retour /auth/callback vérifie que state correspond, échange le code contre les jetons, puis fait vérifier l'ID token par la bibliothèque (signature, iss, aud, exp, nonce) ;
3. l'application retrouve ou crée l'utilisateur local à partir de sub (stable et unique, contrairement à l'adresse mail qui peut changer), puis ouvre sa propre session, avec les réglages du chapitre 5 ;
4. à la déconnexion, elle ferme sa session et peut rediriger vers la déconnexion du fournisseur, pour fermer aussi la session SSO.

Les erreurs d'intégration classiques

Comment l'E7 l'interroge

• SLAM (sujet 2024) : inventorier les comptes de plusieurs applications avant un SSO ; créer un compte SQL aux droits minimaux ; identifier les conséquences d'une API dont aucune route ne vérifie l'utilisateur appelant ; expliquer pourquoi un jeton est refusé après expiration ; compléter le rafraîchissement d'un jeton ; analyser l'effet du SSO sur un scénario de risque. On peut aussi te demander de distinguer ID token et jeton d'accès, ou de repérer une redirect_uri trop permissive.
• SISR : proposer une solution d'authentification unique pour plusieurs applications internes ; relier le fournisseur d'identité à l'annuaire en LDAPS ; traiter la disponibilité du fournisseur d'identité (redondance, sauvegarde).
• Tronc commun : expliquer l'intérêt et le risque du SSO ; distinguer authentification (OIDC) et autorisation déléguée (OAuth 2.0).

Exercices

https://sso.sorbier.example/realms/sorbier/protocol/openid-connect/auth?response_type=token&client_id=intranet&redirect_uri=https://intranet.sorbier.example/retour&scope=profile