Identité fédérée : SAML, OAuth et OpenID Connect

Dans les entreprises modernes, les employés doivent accéder à des dizaines d'applications — applications cloud, outils SaaS, portails partenaires et systèmes internes — dont chacune peut être gérée par une organisation différente. Créer et gérer des comptes distincts pour chacune est peu sécurisé (prolifération des identifiants) et inefficace. La fédération des identités résout ce problème en permettant à un fournisseur d'identité (IdP) — une source d'identité fiable et faisant autorité — d'authentifier les utilisateurs et de partager cette identité authentifiée avec des fournisseurs de services (SP) au-delà des frontières organisationnelles. Les utilisateurs s'authentifient une seule fois et accèdent à plusieurs systèmes sans saisir de nouveau leurs identifiants.

L'authentification unique (SSO) permet aux utilisateurs de s'authentifier une fois et d'accéder à plusieurs applications au cours d'une session sans devoir s'authentifier à nouveau. L'utilisateur se connecte auprès du fournisseur d'identité (Active Directory d'entreprise, Okta, Azure AD), reçoit un jeton de session ou une assertion, puis présente ce jeton à chaque fournisseur de services auquel il accède. Le SSO renforce la sécurité en réduisant le nombre de mots de passe que les utilisateurs doivent gérer (et donc leur réutilisation), en permettant l'application centralisée des politiques d'authentification et en autorisant la révocation immédiate de l'accès à toutes les applications intégrées lorsqu'un compte est désactivé au niveau de l'IdP.

SAML (Security Assertion Markup Language) 2.0 est la norme ouverte fondée sur XML permettant d'échanger des données d'authentification et d'autorisation entre des fournisseurs d'identité et des fournisseurs de services. Le flux SAML se déroule ainsi : (1) l'utilisateur accède à un fournisseur de services (par exemple Salesforce), (2) le SP le redirige vers le fournisseur d'identité (par exemple Okta), (3) l'utilisateur s'authentifie auprès de l'IdP, (4) l'IdP émet une assertion SAML XML signée contenant l'identité et les attributs de l'utilisateur, (5) l'assertion est renvoyée au SP, (6) le SP valide la Signature de l'assertion à l'aide de la clé publique de l'IdP et accorde l'accès. SAML est largement utilisé pour le SSO d'entreprise dans les applications web.

Trois parties participent à une fédération SAML. Le principal est l'utilisateur (ou le système) qui demande l'accès ; il lance le processus d'authentification. Le fournisseur d'identité (IdP) est la source d'identité faisant autorité : il authentifie le principal et émet des assertions. Parmi les exemples figurent Microsoft Azure AD, Okta, Ping Identity et ADFS. Le fournisseur de services (SP) consomme l'assertion et accorde l'accès en fonction de celle-ci. Parmi les exemples figurent Salesforce, Google Workspace, AWS et toute application compatible avec SAML. Le SP et l'IdP établissent leur relation de confiance à l'avance en échangeant des métadonnées contenant les URL de leurs points de terminaison respectifs et leurs certificats de signature.

OAuth 2.0 est un cadre d'autorisation (et non un protocole d'authentification) qui permet à une application tierce d'accéder aux ressources au nom d'un utilisateur sans exposer ses identifiants. Le cas d'utilisation classique est le suivant : « Autoriser cette application de retouche photo à accéder à vos photos Google. » OAuth 2.0 définit quatre rôles : le propriétaire de la ressource (l'utilisateur), le Client (l'application tierce), le serveur d'autorisation (qui émet les jetons) et le serveur de ressources (qui héberge la ressource protégée). L'utilisateur autorise le Client, qui reçoit un jeton d'accès et le présente au serveur de ressources, sans jamais avoir besoin du véritable mot de passe de l'utilisateur.

Le flux de code d'autorisation est le flux OAuth 2.0 le plus sécurisé pour les applications web. Il se déroule ainsi : (1) le Client redirige l'utilisateur vers le serveur d'autorisation avec les portées demandées ; (2) l'utilisateur s'authentifie et donne son consentement auprès du serveur d'autorisation ; (3) le serveur d'autorisation redirige l'utilisateur vers le Client avec un code d'autorisation à durée de vie courte ; (4) le Client échange le code contre un jeton d'accès (et éventuellement un jeton d'actualisation) au moyen d'un appel de serveur à serveur utilisant les identifiants du Client ; (5) le Client utilise le jeton d'accès pour appeler le serveur de ressources. L'échange du code a lieu côté serveur, ce qui empêche l'exposition du jeton d'accès dans l'historique ou les journaux du navigateur.

OpenID Connect (OIDC) est une couche d'authentification bâtie au-dessus d'OAuth 2.0. OAuth fournit uniquement l'autorisation (les jetons d'accès prouvent ce que le Client peut faire) ; OIDC ajoute l'authentification (un jeton ID prouvant l'identité de l'utilisateur). OIDC ajoute la portée openid au flux OAuth et renvoie un jeton ID JWT (JSON Web Token) signé en plus du jeton d'accès. Le jeton ID contient des revendications (nom, adresse e-mail, sub [identifiant du sujet]) qui identifient l'utilisateur. OIDC est désormais le protocole dominant pour le SSO destiné aux utilisateurs finaux : les boutons « Se connecter avec Google/Apple/Microsoft » utilisent tous OIDC.

Les JSON Web Tokens (JWT) sont un format compact et compatible avec les URL permettant de représenter des revendications entre différentes parties. Un JWT comporte trois parties encodées en base64url et séparées par des points : Header (algorithme et type de jeton), Payload (revendications : iss, sub, aud, exp, iat et revendications personnalisées) et Signature (signature cryptographique vérifiant l'intégrité du jeton). Les JWT sont autonomes : le serveur de ressources peut les vérifier sans appeler à nouveau le serveur d'autorisation, ce qui améliore les performances et permet des architectures sans état. L'exigence de sécurité essentielle est la suivante : vérifiez toujours la Signature du JWT et contrôlez les revendications exp (expiration) et aud (audience).

Il est essentiel de comprendre dans quels cas chaque norme s'applique pour l'examen Security+. SAML 2.0 : SSO d'entreprise pour les applications web, flux fondés sur le navigateur et assertions XML. Cette norme est ancienne, mais largement déployée en entreprise. OAuth 2.0 : autorisation d'API, permettant d'accorder aux applications tierces un accès limité aux ressources. Il n'authentifie pas directement les utilisateurs. OIDC : authentification destinée aux utilisateurs finaux et aux entreprises modernes (SSO), bâtie sur OAuth 2.0. Il renvoie des jetons ID JWT identifiant l'utilisateur. En pratique, les environnements d'entreprise utilisent souvent SAML pour le SSO des applications et OIDC pour l'authentification des API et des applications mobiles. Les environnements cloud natifs modernes préfèrent OIDC à SAML en raison de son format JSON/JWT et de sa meilleure prise en charge des appareils mobiles.

Les systèmes de fédération des identités introduisent des vecteurs d'attaque spécifiques. Attaques par rejeu d'assertion : un attaquant intercepte une assertion SAML et la rejoue pour obtenir un accès. Ce risque est limité par des durées de vie d'assertion courtes et des identifiants d'assertion à usage unique. Enveloppement de signature XML (XSW) : dans SAML, les attaquants peuvent parfois manipuler le XML signé afin de modifier les revendications tout en conservant une Signature valide sur le contenu original. Confusion d'algorithme JWT : si un serveur accepte à la fois les algorithmes RS256 (asymétrique) et HS256 (symétrique), un attaquant peut forger des JWT en utilisant la clé publique du serveur comme secret HMAC pour HS256. Validez toujours que l'algorithme indiqué dans l'en-tête correspond à l'algorithme attendu. Redirections ouvertes : les URI de redirection OAuth doivent correspondre exactement afin d'empêcher le vol de jetons par redirection vers des sites contrôlés par un attaquant.

La fédération des identités d'entreprise nécessite souvent de synchroniser les données d'identité des utilisateurs entre les systèmes. SCIM (System for Cross-domain Identity Management) est une norme d'API REST qui automatise le provisionnement et le déprovisionnement des utilisateurs entre un fournisseur d'identité et les fournisseurs de services connectés. Lorsqu'un nouvel employé est ajouté à Azure AD (IdP), SCIM crée automatiquement son compte dans Salesforce, Slack, GitHub et d'autres applications compatibles avec SCIM. Lorsque l'employé quitte l'entreprise, SCIM désactive tous ses comptes simultanément, ce qui réduit la période pendant laquelle des comptes orphelins pourraient être exploités. SCIM complète les protocoles SSO (SAML/OIDC) en gérant le cycle de vie des identités, que ces protocoles ne prennent pas en charge.

Dans cette leçon, vous avez appris que : SAML 2.0 utilise des assertions XML pour le SSO d'entreprise fondé sur le navigateur ; OAuth 2.0 est un cadre d'autorisation permettant de déléguer l'accès aux API ; OpenID Connect ajoute l'authentification (des jetons ID JWT) au-dessus d'OAuth ; et SCIM automatise la gestion du cycle de vie des identités entre les systèmes fédérés. Le cours sur l'authentification et l'autorisation est terminé ; nous allons maintenant étudier les principes fondamentaux de la sécurité réseau.