OIDC ou SAML : lequel vous faut-il vraiment

Toute équipe qui développe un logiciel B2B se heurte au même carrefour la première fois qu'un client sérieux annonce « il nous faut le SSO ». Deux acronymes, OIDC et SAML, prétendant chacun être la réponse, et un internet rempli de tableaux comparatifs qui vous disent que SAML est « entreprise » et OIDC « moderne », pour vous laisser exactement aussi coincé qu'avant. Voici la version qui vous aide vraiment à livrer.

Ce qu'ils sont

SAML date de 2005 et c'est du XML. Un fournisseur d'identité signe une assertion (« voici alice@bigco.com, voici ses groupes ») et la transmet à votre application, qui vérifie la signature et la connecte. Il a été conçu pour le navigateur et pour l'identité des collaborateurs, à une époque où « l'entreprise » signifiait un Active Directory sur site et une pile SOAP. Il est verbeux, il est ancien, et il est absolument partout au sein des grandes organisations, ce qui est le seul fait le concernant qui compte pour vous.

OIDC date de 2014 et c'est du JSON et des JWT, posés sur OAuth 2.0. Un fournisseur d'identité émet un jeton d'identité que votre application valide. Il a été conçu pour le web moderne : SPA, applications mobiles, API, connexion sociale. Il est plus propre, mieux spécifié pour ce que vous construisez réellement aujourd'hui, et c'est le protocole que parle désormais la plupart des nouveaux projets d'identité.

Quand chacun l'emporte

La réponse honnête à « lequel dois-je développer » est que vous n'avez presque jamais le choix. Vous développez celui qu'a choisi le service informatique de votre client, et il l'a choisi bien avant d'avoir entendu parler de vous.

• Un client sous Okta, Entra ID ou Google Workspace peut généralement faire l'un ou l'autre, et OIDC est la voie la plus agréable.
• Un client sous un ADFS plus ancien, un IdP historique sur site ou une grille d'achat rédigée en 2016 vous remettra un bloc de métadonnées SAML et une invitation à un rendez-vous, et la discussion s'arrête là.
• Vos propres applications maison, votre tableau de bord et votre client mobile, veulent OIDC, point final. Vous n'iriez jamais chercher SAML pour connecter un utilisateur à votre propre application React.

Le terrain se divise donc nettement : OIDC pour le moderne et le maison, SAML pour « parce que l'entreprise l'a décidé ». Vendez à suffisamment d'entreprises et on vous demandera les deux. Pas à terme. À répétition.

Les pièges, là où le faire soi-même devient coûteux

Le problème de SAML, c'est qu'il s'agit d'un protocole à XML signé, et le XML signé est l'une des choses les plus régulièrement dangereuses de la cryptographie appliquée. Les façons de rater la vérification de signature SAML sont nombreuses et célèbres :

• Encapsulation de signature (XSW) : un attaquant déplace l'élément signé et glisse une assertion forgée, non signée, là où votre analyseur lit réellement. Si vous vérifiez la signature et lisez l'assertion en deux étapes distinctes, vous êtes probablement vulnérable, et c'est exactement ce que fait presque toute première implémentation.
• Canonicalisation et injection de commentaires : la catégorie de failles de 2018 où user@company.com<!---->.evil.com se canonicalise d'une façon pour la vérification de signature et d'une autre pour la chaîne que lit votre code, si bien que vous authentifiez allègrement la mauvaise personne. De vraies CVE, plusieurs bibliothèques majeures.
• Les plus discrets : signer la réponse mais pas l'assertion, accepter des assertions non signées, faire confiance à l'émetteur fourni par l'IdP sans l'épingler, se tromper sur la fenêtre de validité de l'assertion. Chacun est son propre piège, et chacun a été mis en production par des gens qui savaient ce qu'ils faisaient.

OIDC est nettement plus sain, mais il n'est pas exempt d'arêtes vives. Vous devez tout de même valider les bons claims (iss, aud, exp, le nonce), utiliser PKCE, refuser le flux implicite mort depuis longtemps, et gérer la rotation et la mise en cache des JWKS sans rejeter un jeton signé par une clé que vous n'avez pas encore récupérée. La différence, c'est que les pièges d'OIDC sont documentés, de forme JSON, et gérés correctement par défaut dans la plupart des bibliothèques. Les pièges de SAML sont de forme XML et ont dévoré des équipes de sécurité bien mieux dotées que la vôtre.

La vraie réponse

« OIDC ou SAML » est la mauvaise question, car la bonne réponse pour un produit B2B est « oui ». Vos clients modernes et vos propres applications veulent OIDC. Vos clients grands comptes imposeront SAML selon un calendrier que vous ne maîtrisez pas. Construisez pour l'un, et le troisième appel commercial le casse.

Ce dont vous avez réellement besoin, c'est d'un moyen d'accepter le protocole que chaque client apporte, sans monter deux piles, deux tuyauteries de métadonnées et deux occasions distinctes de rater la vérification de signature. La mise en œuvre, voilà le coût. Le choix n'a jamais été la partie difficile.

C'est précisément ce dont Authagonal vous décharge. Chaque locataire bénéficie de SAML 2.0 avec import de métadonnées en un clic et de fédération OIDC avec les fournisseurs que vos clients utilisent déjà, sur la même page de connexion, sans frais par connexion pour l'un comme pour l'autre. Vous n'implémentez pas la vérification de signature XML, vous ne maternez pas un cache JWKS, et vous ne reconstruisez rien de tout cela quand le prochain client se présente en parlant l'autre protocole. Découvrez ce qui est inclus.