En 2012, celui qui tenait la plume sur OAuth 2.0 a démissionné. Ses raisons se lisent comme une prévision.
En juillet 2012, l'éditeur de la spécification OAuth 2.0 a démissionné. Eran Hammer tenait la plume depuis des années : à l'IETF, l'éditeur est la personne qui rédige le texte normatif et arbitre la conception pendant que le groupe de travail débat, pas un relecteur. Il avait édité avant cela le standard publié OAuth 1.0. Il a retiré son nom de la version 2.0, il est parti, et il a publié un billet très lu intitulé « OAuth 2.0 and the Road to Hell ».
Son grief n'avait rien d'académique. Le protocole, écrivait-il, avait été vidé de sa substance pour devenir « un plan » que chaque éditeur déclinerait en un produit incompatible avec les autres. Il appelait cela « the enterprise way », la « manière WS-* ». Et il prévenait, en toutes lettres, que la version 2.0 « ouvre une toute nouvelle frontière pour vendre des prestations de conseil et des solutions d'intégration ». La RFC 6749 est sortie trois mois plus tard, avec le nom de Dick Hardt à la place du sien.
Quatorze ans plus tard, activer la connexion d'entreprise que réclame votre plus gros client coûte environ 125 dollars par connexion et par mois, ou se trouve derrière un palier nommé « Enterprise », ou derrière un bouton « contacter le service commercial » qui ajoute trois semaines à une échéance sur laquelle vous étiez déjà en retard. Hammer en a vu la forme dès 2012, depuis la pièce où cela se décidait.
Il vaut donc la peine de tout reprendre depuis le début : qui a écrit ces standards, ce que ces gens croyaient construire, et comment cela s'est transformé en ligne de facture. Les douves qui en sont sorties sont réelles. Elles sont aussi faites de deux matériaux différents, et un seul des deux tient encore.
Les protocoles étaient terminés avant la grille tarifaire
En 2015, le travail de normalisation était pour l'essentiel achevé. SAML 2.0 est devenu un standard OASIS en mars 2005, autrement dit il est antérieur à l'iPhone. OAuth 2.0 a été publié en 2012 sous la référence RFC 6749. OpenID Connect a bâti l'identité par-dessus en 2014. SCIM, le protocole qui crée et supprime les comptes d'un système à l'autre, a atteint sa révision 2.0 (RFC 7642 à 7644) en septembre 2015. Les quatre pièces qui composent « l'authentification d'entreprise » étaient spécifiées, interopérables et libres d'implémentation il y a plus de dix ans.
Rien n'a changé de façon significative depuis. Une assertion SAML signée aujourd'hui ressemble à une assertion SAML signée en 2008. Cela écarte la justification habituelle d'un supplément : la nouveauté. L'authentification unique d'entreprise n'est pas une fonctionnalité de pointe dont le développement continu coûterait une fortune, et servir une connexion arrivée par SAML ne coûte pas un centime de plus au fournisseur qu'une connexion par mot de passe. C'est une infrastructure stabilisée. Ce qui pose la question de l'origine du prix, si ce n'est pas l'ingénierie.
Les groupes de travail qui l'ont écrit n'étaient pas des équipes commerciales
Commencez par regarder qui a rédigé les spécifications, car cela explique beaucoup. SAML n'est pas né d'une réunion de tarification. Il est sorti d'un comité technique de l'OASIS, et la présidente fondatrice de ce groupe était Eve Maler, alors directrice technologique chez Sun Microsystems, qui avait passé des années sur les standards de balisage et de fédération qui ont rendu possible la connexion entre entreprises. Le résultat était un document public que n'importe qui pouvait implémenter, gratuitement.
L'état d'esprit de l'époque était l'ouverture, pas l'enclos. En août 2005, à l'OSCON d'O'Reilly, Dick Hardt de Sxip Identity a donné une keynote au rythme effréné intitulée « Identity 2.0 », revue et revisionnée depuis. L'idée était un web où votre identité vous appartient et vous suit, transportée d'un site à l'autre au lieu d'être enfermée dans l'annuaire de chacun. Un an plus tard, OAuth a commencé de la même manière. Blaine Cook, qui construisait l'API de Twitter, cherchait un moyen de laisser une application agir en votre nom auprès d'une autre sans que les utilisateurs livrent leur mot de passe, n'a trouvé aucun standard ouvert pour cela, et s'est assis début 2007 avec Chris Messina, David Recordon et quelques autres pour en écrire un. La première spécification OAuth est sortie la même année. Personne dans ce groupe ne cherchait à bâtir un péage. Ils cherchaient à empêcher le web de demander leur mot de passe aux gens.
Ce contre quoi Hammer mettait réellement en garde
Puis le standard a grandi, et la salle a changé. OAuth 2.0 devait généraliser la première version, et le groupe de travail s'est rempli d'intérêts plus lourds. Comparé à la 1.0, écrivait Hammer en partant, le résultat était devenu « plus complexe, moins interopérable, moins utile, plus incomplet et, surtout, moins sûr ». La comparaison qu'il a choisie, la pile WS-* de la décennie précédente, était l'exemple le plus net qu'ait produit le secteur d'une spécification ouverte transformée en marché de prestations d'intégration.
Relisez cela avec dix ans de recul et c'est une prévision. Ce qui allait finir par être facturé à la connexion était déjà, en 2012, façonné par ceux-là mêmes qui allaient le facturer. OpenID Connect a remis l'identité sur des bases propres au-dessus d'OAuth 2.0 en 2014, rédigé par Nat Sakimura au Nomura Research Institute avec John Bradley et Mike Jones, et c'est un travail réellement solide sur lequel tout le secteur tourne encore. Mais regardez où siégeaient ses auteurs : Bradley chez Ping Identity, Jones chez Microsoft. Les spécifications sont restées ouvertes et libres d'implémentation. Ceux qui les écrivaient travaillaient de plus en plus pour les entreprises qui allaient en vendre le résultat.
Ceux qui ont écrit le standard sont allés le vendre
La couche commerciale n'est pas venue de l'extérieur du monde des standards. Elle en est sortie directement, souvent par les mêmes mains. Eve Maler, qui présidait chez Sun le groupe dont est sorti SAML, a rejoint ForgeRock en 2014 comme VP innovation avant d'en devenir la directrice technique. ForgeRock était elle-même bâtie sur la pile d'identité que Sun avait libérée sous le nom d'OpenSSO, et en 2023 elle a été absorbée par Ping Identity. Ping existe depuis 2002, assez tôt pour avoir contribué à écrire le manuel de la fédération qu'elle a ensuite vendu pendant vingt ans. Rien de tout cela n'était sournois. Le constat est plus étroit et plus étrange : la spécification ouverte et le produit facturé n'ont jamais été deux mondes séparés. La même expertise a écrit les deux.
La génération cloud a hérité du schéma, et l'instinct tarifaire a suivi. Okta a été fondée en 2009 par Todd McKinnon, qui dirigeait l'ingénierie chez Salesforce, et Frederic Kerrest ; elle est entrée en bourse en 2017 et, en 2021, a payé 6,5 milliards de dollars en actions pour Auth0. Auth0, c'était l'offre pensée pour les développeurs, lancée en 2013 par deux ingénieurs argentins, Eugenio Pace et Matías Woloski, qui s'étaient rencontrés en mission de conseil et voulaient réduire l'ajout d'un login à quelques appels d'API. Qu'une entreprise dont toute la promesse était le confort des développeurs vaille malgré tout six milliards et demi de dollars, voilà l'indice : celui qui possède la boîte de connexion possède une route que toutes les autres fonctionnalités doivent emprunter. La vague la plus récente le dit ouvertement dans son marketing. WorkOS, fondée en 2019 par Michael Grinich, vend ce qu'il appelle la traversée du « enterprise chasm » : rendre un produit « enterprise-ready » en fournissant précisément les pièces qui se facturent, à savoir l'authentification unique, la synchronisation d'annuaire, les journaux d'audit. L'authentification unique est la pièce entreprise. C'est là qu'est l'argent. Donc c'est elle qui reçoit une étiquette de prix.
Pourquoi le prix suit votre échéance, pas le code
Rob Chahin a remarqué le schéma et a lancé en 2019 une liste publique sur sso.tax, le « SSO Wall of Shame », qui recense combien les éditeurs facturent l'activation de SAML. Certaines majorations sont absurdes au premier coup d'œil : un forfait de base qui se multiplie plusieurs fois dès que SSO y apparaît. La liste est longue parce que la stratégie fonctionne.
Elle fonctionne à cause du moment où l'acheteur a besoin de la fonctionnalité. Personne ne fait ses courses en SSO un après-midi tranquille. Vous en avez besoin le jour où l'équipe sécurité d'un gros client en fait une condition de signature, ou la semaine où votre propre auditeur SOC 2 vous demande comment vous contrôlez les accès. Vous en avez besoin contre une échéance, avec un contrat ou un certificat en jeu, et vous en avez besoin tout de suite. C'est le moment où un acheteur est le moins sensible au prix de toute sa vie, et la tarification est construite autour de lui. Le supplément n'a jamais été calibré sur le coût marginal d'une implémentation SAML, qui est proche de zéro. Il a été calibré sur le peu de marge de manœuvre qui vous reste le jour où vous en avez enfin besoin.
Voilà la vraie forme de ce qu'on appelle la taxe SSO. Ce n'est pas un prix sur une fonctionnalité. C'est un prix sur une échéance.
De quoi les douves sont réellement faites
Alors, cette position est-elle défendable ? Les douves que tiennent les acteurs installés sont réelles, mais elles sont faites de deux matériaux distincts, et ils ne sont pas également solides.
Le premier est la complexité. SAML est ancien, mais il n'est pas simple à implémenter correctement. Validation des signatures, canonicalisation XML, assertions chiffrées, métadonnées qui tournent, et la longue traîne des particularités que chaque fournisseur d'identité livre à sa façon : tout faire juste, et sûr, représentait historiquement des semaines de travail de spécialiste, et une source abondante de failles de sécurité quand c'était mal fait. SCIM ajoute sa propre surface. Construire cela une fois était un investissement réel. Le construire face à chaque IdP que vos clients peuvent apporter, et l'exploiter de façon fiable, c'étaient des douves derrière lesquelles on pouvait garer une entreprise.
Le second matériau est la confiance. Une équipe sécurité en entreprise doit accepter votre couche d'identité, et cela veut dire SOC 2, tests d'intrusion, antécédents, une société qui existera encore dans cinq ans, et quelqu'un à appeler à deux heures du matin quand la fédération casse. Aucun code astucieux ne raccourcit cela. Cela se gagne lentement, et c'est de loin la moitié la plus dure des douves.
Pendant vingt ans, ces deux moitiés se sont renforcées l'une l'autre, et la tarification les a traitées comme une seule chose indivisible. Ce n'est pas une seule chose.
La moitié des douves que l'IA est en train de vider
Voici ce qui a changé. La moitié complexité de ces douves était au fond un problème de connaissance et de main-d'œuvre : les protocoles sont bien spécifiés et abondamment documentés, mais les câbler correctement demandait une expertise rare, chère, et beaucoup d'heures. C'est exactement le genre de problème où les assistants de code par IA sont bons. Un standard stabilisé, vieux de vingt ans, avec des implémentations de référence publiques en abondance, est à peu près leur meilleur cas de figure. Un travail qui exigeait autrefois un spécialiste de l'identité pendant un mois demande de plus en plus un ingénieur compétent et un bon assistant pendant une semaine.
Attention à ce que cela érode et à ce que cela n'érode pas. Cela ne touche pas la moitié confiance. L'IA ne vous remet pas un SOC 2, ni une réputation en sécurité, ni une astreinte, et s'il faut choisir, le flot de code d'authentification produit par des machines rend un fournisseur audité et éprouvé plus précieux, pas moins. Mais elle passe la tronçonneuse dans la moitié complexité. Cela compte, parce que la tarification s'appuyait discrètement sur les deux moitiés à la fois. Quand implémenter SAML cesse d'être des douves et devient un week-end, « réservé à l'offre entreprise » ne dit plus rien sur ce qui est difficile à construire. Cela dit ce que le fournisseur a choisi de facturer. L'écart de capacité se referme plus vite que la grille tarifaire ne l'admet.
Une petite équipe qui donne les fonctionnalités taxées
Nous sommes un point de données dans cette discussion. Authagonal est une petite équipe, et l'authentification unique, SAML et SCIM ne sont pas notre option payante ; ils sont sur l'offre gratuite, connexions illimitées, jusqu'à 250 utilisateurs actifs par mois, sans carte bancaire. Les offres payantes commencent à 29 dollars par mois et portent le même ensemble de fonctionnalités à chaque palier. Comparez cela au tarif du marché pour la capacité identique : WorkOS facture l'authentification unique environ 125 dollars par connexion et par mois, et SCIM 125 de plus ; Clerk vous donne une connexion, puis environ 75 dollars par connexion supplémentaire ; Auth0 offre une connexion jusqu'à 25 000 utilisateurs, puis renvoie le SSO en production vers sa gamme professionnelle plus chère. Nous ne sommes pas moins chers parce que nous avons trouvé une astuce. Nous sommes moins chers parce que la fonctionnalité ne coûte presque rien à fournir, et que nous avons refusé de la facturer comme si elle était rare.
Rien de tout cela ne signifie que les acteurs installés sont sur le point de tomber. La moitié confiance de leurs douves est réelle, et ils ont passé vingt ans à la bâtir. Mais l'histoire selon laquelle l'authentification d'entreprise coûte cher parce qu'elle est difficile devient de plus en plus dure à raconter sans sourire, au moment précis où les outils qui la rendent facile arrivent entre toutes les mains. Pour voir ce que coûtent ces fonctionnalités une fois que vous cessez de payer la taxe, notre page tarifs les met toutes sur la même offre, et le calculateur de taxe SSO chiffrera votre configuration exacte face aux fournisseurs qui la facturent encore.