Développer ou acheter son auth : la facture que vous ne voyez pas venir

L'authentification est la fonctionnalité que chaque ingénieur est certain de pouvoir construire en un week-end, et il a raison. Vous pouvez construire un formulaire de connexion, une table d'utilisateurs et un e-mail de réinitialisation de mot de passe avant dimanche soir. Le week-end est réel. Mais le week-end n'est pas le coût. Le coût, c'est tout ce qui arrive ensuite, selon un calendrier que vous ne fixez pas, pour un système que vous ne pouvez jamais éteindre.

La partie que vous croyez être le travail

E-mail et mot de passe. Une table de sessions. Un lien « mot de passe oublié » qui envoie un jeton par e-mail. La connexion sociale si vous vous sentez consciencieux. Cela tient véritablement en un week-end, et si c'était là tout le travail, vous devriez absolument le développer vous-même. Ce n'est pas tout le travail, et vous le savez, et c'est pourquoi vous lisez un article sur le « développer ou acheter » au lieu de simplement le développer.

La facture que vous ne voyez pas venir

Vous possédez désormais une surface de sécurité, à perpétuité. Le hachage des mots de passe, et le re-hachage de chaque utilisateur le jour où vous réalisez que votre facteur de coût bcrypt avait été réglé pour le matériel de 2019. La limitation de débit et le verrouillage de compte. Le credential stuffing, parce que votre point de terminaison de connexion rejoint toutes les listes de rejeu de fuites dans le mois qui suit le lancement. Et le gros morceau : la responsabilité. Le jour où vous stockez des identifiants, vous devenez une cible, et une fuite cesse d'être un risque abstrait dans la présentation commerciale de quelqu'un d'autre. C'est votre incident, votre e-mail de notification, la confiance de vos clients, et peut-être votre régulateur.

Le travail sur les protocoles débarque dès que vous vendez à quelqu'un de sérieux. Le SSO d'entreprise, c'est SAML, et SAML, c'est la vérification de signature XML, qui constitue son propre genre de CVE (vous ne voulez vraiment pas croiser l'encapsulation de signature en production ; plus de détails ici). SCIM, c'est construire le provisionnement et le déprovisionnement, et le déprovisionnement est un contrôle de sécurité : ratez-le et un employé licencié conserve ses accès. MFA, c'est l'enrôlement, les codes de récupération, et la file de support quand quelqu'un perd son téléphone. Les journaux d'audit, c'est la rétention et l'inviolabilité, parce que l'auditeur SOC 2 du client posera la question, et « on écrit dans un fichier quelque part » n'est pas une réponse.

La traîne opérationnelle ne finit jamais. La rotation des clés et les JWKS. L'invalidation de session qui fonctionne réellement sur tous les appareils. La révocation de jetons. Et l'astreinte, pour le seul système de votre pile qui, lorsqu'il tombe, emporte tout avec lui : plus personne ne se connecte, plus aucun appel d'API ne s'authentifie, tout votre produit n'est qu'une page 500. L'auth est de niveau zéro. Vous vous engagez à maintenir en marche un système de sécurité de niveau zéro pour toujours, avec les mêmes effectifs que vous comptiez consacrer à votre véritable produit.

La traîne de conformité est annuelle. SOC 2, ISO 27001, le questionnaire de sécurité d'un prospect : chacun interroge, en détail, chaque point ci-dessus. Les auditeurs ne sont pas charmés par « on l'a fait maison ». Acheter son auth vous permet de pointer vers les contrôles d'un fournisseur ; le développer fait de ces contrôles les vôtres, à documenter, prouver et défendre, chaque année.

Quand développer est vraiment le bon choix

Ce n'est pas un argumentaire du type « achetez, toujours », car ce serait malhonnête et vous le verriez tout de suite. Développez votre propre auth quand :

• C'est un petit outil interne derrière un VPN, une poignée d'utilisateurs, aucune surface de conformité. Le week-end est vraiment tout le travail.
• L'auth est votre produit. Si vous montez une entreprise d'identité, construisez de l'identité. C'est votre facteur de différenciation, pas vos frais généraux.
• Vous avez des besoins véritablement atypiques auxquels aucun fournisseur ne répond, et une équipe de sécurité dédiée qui possédera le résultat toute sa vie durant. Notez les deux moitiés de cette phrase. L'équipe est la moitié coûteuse.

En dehors de ces cas, le calcul est plus simple qu'il n'y paraît. Le coût de « développer » n'a jamais été le premier week-end. C'est la possession perpétuelle d'un système critique pour la sécurité qui ne rend votre produit en rien meilleur, seulement plus vôtre.

Le recadrage honnête

Développer son auth ne rend votre produit plus précieux pour aucun client. Personne n'a jamais acheté votre logiciel parce que vous aviez implémenté à la main la vérification de signature SAML. Cela ne fait que transformer l'auth, problème de quelqu'un d'autre, en le vôtre, pour toujours, et dépense l'ingénierie que vous auriez pu consacrer à ce pour quoi les gens paient réellement.

L'objection habituelle à l'achat, à savoir que les fournisseurs d'auth font payer une fortune pour activer les fonctionnalités d'entreprise, est réelle. Mais c'est un argument sur quel fournisseur, pas sur développer ou acheter. Une bonne partie de cette facture est une taxe sur les fonctionnalités que vous n'avez pas à payer. Achetez un auth qui inclut SSO, SCIM, MFA et journaux d'audit sans le péage par connexion, et la question développer ou acheter se répond en grande partie d'elle-même.

Avant de consacrer un sprint à un système de connexion, il vaut la peine de voir exactement ce que les clients grands comptes en exigeront. Voici ce qui est inclus, sur chaque forfait.