SAML
Définition
Security Assertion Markup Language. Protocole de SSO utilisé par les grandes entreprises pour fédérer leurs comptes employés vers les SaaS internes. Indispensable pour cibler des clients ETI ou groupes.
Comment ça marche
SAML 2.0 (Security Assertion Markup Language) est un protocole basé sur XML qui permet de fédérer l'identité entre un fournisseur d'identité (IdP) et une application (SP, Service Provider). L'IdP (Okta, Azure AD, Google Workspace, OneLogin) gère les comptes des employés. Quand un utilisateur veut accéder à votre SaaS, il est redirigé vers son IdP, s'authentifie là-bas, puis l'IdP renvoie une assertion SAML signée à votre application. Votre app valide la signature, lit les informations sur l'utilisateur (email, nom, groupes), et le connecte. L'échange utilise XML signé et chiffré, sur des endpoints standardisés.
À quoi ça sert
SAML est l'outil des grandes entreprises pour garder le contrôle sur les accès de leurs employés à tous les SaaS qu'elles utilisent. Quand un employé arrive, l'IT crée un compte central qui débloque automatiquement Salesforce, Slack, Notion, votre SaaS, et tous les autres outils. Quand l'employé part, on désactive un seul compte, tous les accès sont coupés instantanément. C'est une exigence de sécurité (révocation centralisée), de conformité (audit unique), et de productivité (un seul mot de passe). Pour un SaaS B2B qui vend à des ETI ou des grands comptes, c'est rapidement un critère bloquant.
SAML vs OAuth/OIDC
OAuth et OIDC sont les standards modernes, basés sur JSON, plus simples à implémenter. SAML est plus ancien (lancé en 2005), basé sur XML, plus lourd. Pourquoi SAML survit-il ? Parce que les grandes entreprises ont des infrastructures historiques (Active Directory, Okta) qui le supportent nativement, et migrer tout vers OIDC prendrait des années. En 2026, beaucoup d'IdP supportent les deux : Okta peut faire SAML pour les vieux SaaS, OIDC pour les modernes. Si on développe un SaaS aujourd'hui, on commence avec OIDC, et on ajoute SAML quand le marché entreprise le demande.
Le coût d'implémentation
SAML est complexe : parser du XML, valider des signatures cryptographiques, gérer les certificats, supporter les variations de configuration entre IdP. Implémenter SAML soi-même prend facilement 1 à 2 mois pour un produit production-ready. C'est pourquoi des services comme WorkOS, BoxyHQ Jackson, ou SSOReady existent : ils encapsulent toute la complexité SAML derrière une API simple. Pour 100 à 1000$/mois selon le volume, on évite les semaines d'ingénierie. Sur un SaaS qui démarre, c'est presque toujours rentable. Sur un produit mature avec des dizaines de clients SAML, on peut amortir l'implémentation maison.
Quand l'utiliser
On ajoute SAML quand on commence à vendre à des comptes enterprise. C'est quasi systématiquement demandé dès qu'on dépasse 500 employés côté client. C'est aussi attendu pour les secteurs régulés (banque, santé, défense) qui ont des exigences IT strictes. Sur un MVP ou un SaaS qui cible des PME et startups, SAML peut attendre : OAuth Google/Microsoft suffit, et le coût de mise en œuvre n'a pas de retour immédiat. La règle pratique : on prévoit l'architecture pour supporter SAML dès le début, on l'active quand le premier prospect enterprise le demande.
Les outils
WorkOS est le leader pour les SaaS modernes : SDK Next.js, expérience développeur excellente, supporte SAML + SCIM + Directory Sync, pricing à 125$/mois pour les premiers clients. BoxyHQ Jackson est l'alternative open-source, auto-hébergeable, parfaite pour les contraintes de souveraineté. Auth0 propose SAML dans son plan Enterprise. Clerk vient d'ajouter SAML en 2024 et reste compétitif sur l'expérience UI. Pour les très gros volumes, on peut implémenter directement avec passport-saml ou samlify, mais c'est rarement le bon arbitrage.
Les pièges à éviter
Le piège classique : tester avec un seul IdP (souvent Okta) et découvrir en prod que Azure AD ou Google Workspace renvoient les assertions différemment. On teste avec au minimum 3 IdP majeurs avant de promettre SAML à des clients. Autre piège : ne pas gérer le Just-in-Time provisioning (créer automatiquement l'utilisateur côté SaaS à la première connexion SAML), ce qui force l'admin à créer chaque compte à la main. Ne pas supporter le SAML logout : un employé qui se déconnecte de l'IdP doit aussi être déconnecté de votre SaaS. Et toujours vérifier la signature de l'assertion : un SAML mal validé est une porte d'entrée totale.