L'authentification unique est un standard stabilisé depuis plus de vingt ans, et pourtant SAML reste la ligne de facture qui bloque un contrat ou déclenche un appel au service commercial. Comment l'authentification d'entreprise est devenue une option payante, qui a bâti ce monde et qui nous avait prévenus, quelle est la largeur réelle des douves et de quoi elles sont faites, et la force qui en vide discrètement la moitié.
La supervision est le code qui ne s'exécute que pendant une catastrophe, le seul moment où l'on ne peut pas le trouver cassé. Nous avons donc bâti un harnais qui envoie un vrai signal pour chaque règle d'alerte et ne réussit que lorsque la notification atterrit physiquement dans un relais de capture. Le premier passage a trouvé notre alerte phare sur le taux d'erreurs morte, puis pire: un réglage de rétention imposait une expiration instantanée à nos journaux.
Cent mégaoctets de captures d'écran sont partis vers Cloudflare R2, derrière une base CDN que l'app déduit à l'exécution de son nom d'hôte. Dans le navigateur tout marchait, mais le trafic d'origine n'a pas bougé : les pages que voit un robot sont prérendues sur 127.0.0.1, où le nom d'hôte ne dit rien. La solution : un espace réservé que le HTML emporte hors du build et que l'edge remplit par requête, à cause d'un système de fichiers en lecture seule.
Le provisionnement juste-à-temps était activé par défaut, si bien qu'un fournisseur d'identité fédéré pouvait créer des comptes dans le tenant d'un client en affirmant que quelqu'un existait. Le désactiver est un changement d'un seul mot. Le faire sans modifier en silence le comportement de chaque connexion stockée, dont aucune n'a jamais écrit la colonne, voilà le vrai problème, et l'astuce qui l'a résolu explique pourquoi un réglage par défaut est une surface d'API.
Un backend-for-frontend sort les jetons OAuth du navigateur et ne lui laisse qu'un cookie opaque. Servir de nombreux locataires depuis un seul BFF relève surtout de la tuyauterie, jusqu'à l'arrivée de la déconnexion back-channel : un POST de serveur à serveur sans cookie, sans session et sans navigateur, où la seule chose qui identifie le locataire est une revendication contenue dans un jeton que vous n'avez pas encore vérifié.
Nous avons ajouté à notre cluster Kubernetes un webhook d'admission qui vérifie les signatures, pour qu'aucune image non signée ne puisse jamais s'exécuter. Quelques heures plus tard, un Deployment comptait 2 242 ReplicaSets, un nouveau toutes les trois secondes, et aucun pod disponible. Les logs du webhook montraient qu'il admettait chaque requête. Les dégâts venaient du seul mot de "mutating admission webhook" que nous avions cessé de lire.
Un utilisateur récurrent voyait « Loading… » pendant précisément dix secondes avant chaque connexion. Le chiffre rond était l'indice : notre bibliothèque SSO ouvrait une iframe cachée de renouvellement silencieux vers un hôte servant X-Frame-Options: DENY et frame-ancestors 'none', si bien qu'elle ne se chargeait jamais, ne levait aucune erreur, et la bibliothèque épuisait son délai. Défense anti-clickjacking et renouvellement OIDC, chacun correct, figés dans la jointure.
Nous avons chiffré chaque e-mail au repos, et la recherche d'administration a cessé d'autocompléter : aucune erreur, aucun log. Un blind index restaure la correspondance exacte sur du texte chiffré, mais le rôle de HMAC est de détruire l'ordre dont la recherche par préfixe a besoin. Voici la conception qui a rendu la saisie semi-automatique (indexer chaque préfixe comme une valeur) et les trois pièges qui prouvent que le chiffrement interrogeable est un problème de systèmes, pas de crypto.
Nous avons migré la signature de nos JWT de RS256 vers ES256, et chaque jeton émis était cryptographiquement valide... et rejeté. Trois fois, pour trois raisons différentes : du DER là où JWS attend du R‖S brut, un padding d'entiers qui échoue sur un jeton sur 128, et un dialecte base64 qui a changé sous nos pieds. Voici comment lire les octets massacrés et désigner la couche coupable rien qu'à la longueur de la signature.
Les deux documents qu'un service lit pour valider l'un de nos JWT — le document de découverte et le JWKS — sont les ressources les plus demandées et les moins secrètes que nous servons, et chaque récupération devait autrefois remonter jusqu'à l'origine. Les mettre en cache sur Cloudflare, c'était la partie facile.
Le palier LITE de Duende coûte $5,750/yr mais plafonne à 2 applications clientes et n'inclut aucun SAML. Dès que vous avez besoin de SSO d'entreprise ou d'une troisième application, vous basculez sur STANDARD à $12,500. Un examen de ce que Duende coûte réellement à un vrai produit, et de la taxe au nombre d'applications dont personne ne vous prévient.
Une seule clé privée signe chaque jeton émis par notre serveur d'authentification, et elle a déménagé deux fois au cours de sa vie : née à l'intérieur du processus, exilée dans un coffre-fort dont elle ne peut plus sortir, puis réincarnée en un type de clé entièrement différent, plus petit et plus rapide. Chaque déplacement a eu lieu sur un émetteur en production, avec des jetons en circulation.
Votre SP a validé la signature de l'assertion, épinglé le certificat et connecté l'utilisateur. Tous les contrôles ont réussi. J'ai quand même rejoué une connexion que j'avais capturée il y a une heure. L'astuce n'était pas de casser la signature. C'était de supprimer un champ que la signature ne couvrait pas.
Nous demandions le second facteur sur la page de connexion, sans jamais le revérifier au token endpoint. Résultat : un mot de passe valide plus une URL de retour modifiée à la main passait devant la MFA sans s'arrêter. Le correctif, et la règle qu'il nous a apprise : la MFA est une propriété de la session que vous émettez, pas une étape de l'écran de connexion.
SCIM est une API CRUD standardisée dont le verbe le plus important est celui qui désactive le compte d'un ex-salarié. Les fournisseurs la facturent 125 $ par mois et par connexion, ou la rangent dans l'offre entreprise à côté du SSO. Voici ce qu'une connexion SCIM coûte réellement à servir, et pourquoi faire payer le déprovisionnement revient à faire payer la sécurité.
Azure Table Storage et DynamoDB n'ont pas de marqueurs de suppression : une ligne supprimée disparaît, tout simplement, et votre sauvegarde incrémentale ne voit donc jamais la suppression. Restaurez cette sauvegarde et l'utilisateur parti est de retour, avec le mot de passe que la rotation était censée éliminer. Voici pourquoi les suppressions doivent être traitées comme des données de premier rang, et la table qui le permet.
Notre rate limiter et notre compteur de verrouillage se basaient sur l'IP du client. Derrière nginx, cette IP venait d'un header que le client pouvait définir : un header qui tourne à chaque requête donnait donc à chacune une IP toute neuve, et tous les contrôles par IP s'effondraient. Le spoof en une ligne, et le fix, plus délicat qu'il n'en a l'air sur Kubernetes.
Azure Table Storage vous donne une partition key, une row key, et presque rien d'autre. Pas de jointures, pas d'index secondaires dignes de ce nom, pas d'incrément. On y fait quand même tourner un système d'authentification multi-tenant. Les patterns qui rendent ça possible, et ce qu'on abandonne face à SQL.
Un endpoint de réinitialisation de mot de passe non authentifié, sans limitation de débit par e-mail, n'est pas seulement votre problème. Pointez-le vers la boîte de réception de quelqu'un d'autre et vous avez transformé votre formulaire de réinitialisation en canon à spam, facturé à votre réputation d'expéditeur. La solution, sans révéler quelles adresses e-mail possèdent un compte.
La plupart des fournisseurs d'authentification enferment le SSO, SCIM, la MFA et les journaux d'audit derrière un plan Enterprise. Nous, nous avons tout mis dans l'offre à $0. Voici l'économie unitaire qui rend cette générosité viable : la vraie barrière n'a jamais été les fonctionnalités, ce sont les utilisateurs actifs et le support.
L'authentification unique implique de faire confiance au fournisseur d'identité. Nous lui avons fait confiance pour une chose de trop : nous résolvions les utilisateurs fédérés récurrents par l'e-mail de l'assertion, si bien que n'importe quelle connexion pouvait revendiquer l'adresse d'autrui et accéder à son compte. Le correctif n'était pas plus de validation, mais le passage de la clé de jointure de l'e-mail à un sujet propre au fournisseur, infalsifiable par la partie qui affirme.
Azure Container Apps promettait de ne plus nous faire payer pour un cluster d'authentification inactif. Nous avons chiffré la migration puis nous l'avons abandonnée, pas pour une question de prix ni de démarrages à froid, mais parce que le serverless n'a pas le seul nombre dont une backplane d'authentification à élection de leader a réellement besoin.
La « taxe sur les fonctionnalités » sous forme de vraie facture. Trois scénarios d'acheteur (premier contrat enterprise, une poignée de clients, le SSO devenu incontournable) chiffrés face aux tarifs publics de chaque fournisseur. Plus le surcoût discret dont personne ne vous prévient : manquer de clients OAuth en pleine intégration.
Un cluster à trois réplicas était constamment en désaccord avec lui-même. La cause était dans notre propre code : la routine de découverte de pairs avait un bloc catch qui désactivait la découverte dès que le multicast échouait, et sur du Kubernetes managé, le multicast échoue toujours. Pourquoi nous avons entièrement supprimé le gossip et élu un leader via un blob lease, et pourquoi une appartenance ouvrable dans Storage Explorer vaut mieux qu'une qu'on doit déduire.
Le login, c'est un week-end. La facture arrive après : vérification de signature, déprovisionnement SCIM, MFA, journaux d'audit, rotation des clés, responsabilité en cas de fuite, et astreinte pour un système de niveau zéro. Un comparatif honnête entre développer et acheter, y compris les cas où développer est le bon choix.
OIDC ou SAML ? Vous avez rarement le choix. Ce qu'est chaque protocole, quand chacun l'emporte, les pièges de signature XML qui rendent SAML dangereux à implémenter soi-même, et pourquoi un produit B2B finit par avoir besoin des deux.
Le système de support d’Authagonal : messagerie en temps réel sans actualisation, traduction IA transparente dans les deux sens, fixée dès le premier message du client, et un fil qui reste entièrement traduit, même par e-mail. Simple, élégant et réellement à la hauteur.
Deux de nos tenants étaient discrètement le même tenant : même base de données, même clé de signature de jeton, des noms différents. La cause venait d'une fonction utilitaire d'une seule ligne qui assainissait les slugs en supprimant les traits d'union, transformant un identifiant unique en un identifiant non unique. Voici comment une transformation de chaîne avec perte est devenue une prise de contrôle inter-tenants, et pourquoi nous l'avons découverte avant vous.
Nous vendons de l'authentification, donc notre test le plus important est celui qui devient un client : une unique exécution Playwright qui inscrit un locataire, configure chaque fonctionnalité, dirige une vraie application vers lui, connecte un vrai utilisateur avec les bons claims, puis sauvegarde, restaure et se supprime. Comment des tests de bout en bout exhaustifs nous ont valu notre confiance pour le go-live.
Notre console du personnel s'authentifie via Authagonal lui-même, avec Entra SSO et SCIM qui gèrent le provisioning. Être son propre client fait remonter les cas limites auxquels aucune suite de tests ne pense. Voici ceux qui comptaient.
Votre état Terraform est une carte complète de votre cloud doublée d'un tas de secrets, et par défaut il vit derrière un endpoint public. Voici comment nous avons amorcé l'état distant à partir de rien, l'avons placé derrière un endpoint privé et l'avons atteint via un connecteur zero-trust plutôt que de payer la taxe de la passerelle VPN, sans jamais nous verrouiller dehors.
"Tout le monde réinitialise son mot de passe" est un choix de migration, pas une loi de la physique. Comment reprendre les empreintes de mot de passe existantes de vos utilisateurs lors d'un changement de fournisseur d'identité pour que la bascule soit invisible, et le seul cas où c'est vraiment impossible.
L'industrie de l'authentification facture la permission, pas le coût. Elle verrouille le SSO, le MFA et le provisioning derrière des paliers et des frais par connexion, pour des fonctionnalités dont la fourniture ne coûte pratiquement rien. Voici la distinction que les pages tarifaires espèrent que vous ne tracerez jamais.
Passer du Duende IdentityServer auto-hébergé à l'auth managée : ce qui migre réellement depuis la configuration SQL et ASP.NET Identity, et le coût opérationnel que vous cessez de porter.
Un regard pratique sur ce qu'implique réellement une migration depuis Auth0 : ce qui est facile, ce qui est délicat, et la seule chose qu'Auth0 ne vous donnera franchement pas.