SAML

SAML (Security Assertion Markup Language) est un standard d’authentification unique (SSO) basé sur XML publié par OASIS en 2005. Très utilisé dans les intégrations B2B d’entreprise — Okta, Ping Identity, Microsoft AD FS, Google Workspace, chaque SaaS vendu aux grandes entreprises.

Le modèle : un fournisseur d’identité (IdP, ex. Okta) authentifie l’utilisateur. L’utilisateur arrive chez un fournisseur de services (SP, ex. Salesforce) avec une assertion SAML signée prouvant son identité. Le SP vérifie la signature par rapport à la clé publique de l’IdP et fait confiance à la déclaration.

SAML vs OAuth2/OIDC : SAML est plus ancien, basé sur XML, conçu pour le SSO d’entreprise. OAuth/OIDC sont basés sur JSON, conçus à l’origine pour l’autorisation déléguée (“autoriser cette application à lire mon Gmail”) et étendus ultérieurement à l’authentification (OIDC). Les nouvelles intégrations d’entreprise utilisent de plus en plus OIDC ; les SaaS d’entreprise existants nécessitent souvent encore SAML car les IdP des clients l’exigent.

La spec de signature XML utilisée par SAML est notoirement piégeuse — des attaques de wrapping de signature XML existent sur de nombreuses implémentations. Les bibliothèques modernes (par exemple python-saml, OneLogin) gèrent cela correctement par défaut ; implémenter sa propre solution est une mauvaise idée.

Les liaisons SAML — comment l’assertion circule : SAML définit plusieurs liaisons de transport. HTTP Redirect compresse et encode en base64 la requête dans une chaîne de requête URL (limité par la longueur de l’URL du navigateur) ; HTTP POST envoie un blob encodé en base64 dans un formulaire auto-soumis via JavaScript (le plus courant en 2026) ; HTTP Artifact transmet un jeton de référence court que le SP échange hors bande pour l’assertion complète. L’assertion elle-même est enveloppée en base64 et signée avec SHA-256.

Pièges opérationnels dans les déploiements SAML d’entreprise : décalage d’horloge entre l’IdP et le SP (les assertions ont une fenêtre de validité de 5 minutes par défaut — une heure de serveur mal configurée casse la connexion pour tout le monde), rotation des certificats (le certificat de signature de l’IdP expire tous les 1 à 3 ans et doit être renouvelé avant cette date ou tout le SSO échoue simultanément), et incompatibilités de format NameID. Référence : Spécification SAML 2.0 Core OASIS.

Exemple concret

Un employé clique sur “Se connecter avec le SSO de l’entreprise” sur app.example.com. Le SP génère un document XML SAML <AuthnRequest> et le poste à l’IdP sur sso.acme.com/saml. L’IdP authentifie l’utilisateur (probablement via mot de passe + WebAuthn) et renvoie une SAML <Response> contenant une <Assertion> avec : l’e-mail de l’utilisateur (NameID), les appartenances aux groupes (AttributeStatement), la fenêtre de validité (NotBefore / NotOnOrAfter ~5 minutes) et la restriction d’audience (doit être exactement app.example.com). Le XML est signé avec la clé RSA-2048 de l’IdP en utilisant SHA-256. Le navigateur poste automatiquement ce blob encodé en base64 vers app.example.com/saml/acs. Le SP vérifie la signature par rapport au certificat public pré-partagé de l’IdP, vérifie la fenêtre de validité et l’audience, extrait l’e-mail et crée une session locale. L’ensemble de l’échange représente deux redirections HTTP et est invisible pour l’utilisateur au-delà de l’écran de connexion de l’IdP.

Quand et pourquoi cela importe

Si vous vendez un SaaS B2B, la prise en charge de SAML est la fonctionnalité clé pour les ventes aux entreprises — la plupart des entreprises de plus de 500 employés exigent que tous les accès SaaS passent par leur IdP pour le contrôle du départ des employés. La liste de contrôle défensive pour toute implémentation SAML : valider la signature sur chaque assertion (pas seulement l’enveloppe de réponse), valider InResponseTo pour prévenir la relecture, valider l’audience et le destinataire, appliquer strictement la fenêtre temporelle, et stocker l’empreinte du certificat de l’IdP hors bande. Référence : OWASP SAML Security Cheat Sheet.