Les développeurs de l'Auth Stack abandonnent Auth0 pour

L'identité gérée peut sembler être un raccourci jusqu'à ce que la facture arrive. Des services comme Auth0 et Okta facturent par utilisateur actif mensuel, donc un produit qui passe de 10 000 à 100 000 utilisateurs peut voir ses coûts d'authentification exploser, passant de centaines à des dizaines de milliers de dollars par mois. Pour les applications B2C avec un trafic irrégulier, ce compteur d'utilisateurs actifs mensuels devient une taxe sur la croissance plutôt qu'un poste budgétaire prévisible.

Le verrouillage fournisseur amplifie la douleur. Une fois que vous intégrez vos flux de connexion, règles et métadonnées utilisateur dans un moteur de règles propriétaire, migrer devient comparable à une chirurgie à cœur ouvert. Les actions personnalisées, les jetons propriétaires et les pages de connexion hébergées incitent toutes les équipes à continuer à payer plutôt qu'à refondre la logique d'authentification fondamentale.

Des écosystèmes strictement contrôlés promettent la sécurité mais délivrent souvent de la rigidité. De nombreux fournisseurs vous obligent à passer par leurs interfaces utilisateur hébergées, leurs SDK et leurs processus imposés, rendant même des personnalisations simples — comme l'ajout d'une nouvelle étape de vérification ou le support d'un SSO hérité bizarre — semblables à un combat contre la plateforme. Lorsque vous avez besoin d'un parcours de connexion non standard, vous découvrez à quel point vous avez réellement peu de marge de manœuvre.

La propriété des données ajoute une couche supplémentaire d'inconfort. Les identités des utilisateurs, les sessions et les journaux d'audit se trouvent dans le cloud de quelqu'un d'autre, régis par des politiques internes opaques et des limites de taux. Des API d'exportation existent, mais elles offrent rarement un contrôle de bas niveau sur les schémas, les indices ou la durée pendant laquelle les données persistent réellement dans les sauvegardes.

Pour les startups dans des secteurs régulés, ces contraintes entrent en collision avec la réalité rapidement. Des règles strictes de résidence des données dans l'UE, la santé ou la fintech exigent souvent que les tables utilisateur soient situées dans une région spécifique ou même dans un cluster de bases de données particulier. Lorsque la réponse de votre fournisseur est « notre feuille de route » ou une région réservée aux entreprises, votre équipe de conformité commence à se demander pourquoi l'authentification est externalisée.

Les développeurs réagissent en exigeant plus de contrôle, plus de transparence, et la capacité de posséder l'ensemble de la pile. Les systèmes open-source tels qu'Ory Kratos inversent le modèle : vous gérez le serveur d'identité vous-même, définissez vos propres schémas et conservez les données utilisateurs dans votre propre base de données. L'authentification gérée a encore sa place—mais les menottes dorées commencent à se sentir beaucoup plus serrées.

Les plateformes d'authentification gérées veulent être votre tout. Ory Kratos ne veut être que votre moteur d'identité. Il est conçu en tant que serveur d'identité uniquement backend, axé sur l'API, qui s'intègre derrière n'importe quelle interface utilisateur, framework ou appareil que vous utilisez — Next.js, mobile, applications à page unique, même des monolithes hérités — sans vous obliger à utiliser un widget ou un tableau de bord propriétaire.

Kratos expose chaque opération d'authentification majeure via des APIs HTTP : inscription, connexion, gestion de profil, récupération et paramètres. Votre frontend n'a jamais à stocker la logique des mots de passe ou à créer des liens magiques ; il orchestre simplement des flux définis et sécurisés par Kratos. Cette séparation fait que l'authentification se ressent comme n'importe quel autre microservice interne, et non comme un produit SaaS opaque.

D'emblée, Kratos gère les flux essentiels que la plupart des applications finissent par reconstruire de manière médiocre. Vous bénéficiez d'une inscription utilisateur avec validation basée sur un schéma, d'une connexion par mot de passe, et d'une authentification multifactorielle (MFA) optionnelle pour les comptes à haut risque. Il gère également la vérification des e-mails, l'activation des comptes et une gestion robuste des sessions, y compris la révocation et la rotation des sessions.

Les flux se comportent comme des machines d'état que vous contrôlez via la configuration. Vous pouvez définir où les utilisateurs atterrissent après leur inscription, quels champs ils doivent remplir et comment fonctionnent les liens de récupération ou de vérification. Pour la plupart des applications, cela signifie pas de code glue personnalisé pour « mot de passe oublié », « vérifiez votre e-mail » ou « mettre à jour le profil » au-delà de la connexion de l'interface utilisateur.

Auto-hébergé par conception, Kratos fonctionne partout où Docker fonctionne : un ordinateur portable, un cluster Kubernetes ou une machine bare-metal dans un placard. Le démarrage rapide officiel utilise un seul fichier `docker-compose`, mais la même image de conteneur peut être étendue à des déploiements multi-nœuds. Pas de verrouillage de région, pas de chemin de migration forcé, pas de fenêtres de maintenance opaques.

Le stockage reste sous votre contrôle. Kratos prend en charge des bases de données comme SQLite pour le développement local et PostgreSQL pour la production, connectées via un DSN simple dans sa configuration YAML. Vous possédez la table des utilisateurs, la traçabilité des audits et les sauvegardes, ce qui est important pour le RGPD, le SOC 2 et pour les clients qui demandent : « Où sont exactement mes données stockées ? »

L'auto-hébergement élimine également l'anxiété liée à la tarification basée sur les utilisateurs actifs mensuels. Au lieu de payer Auth0 ou Okta chaque fois que votre nombre d'utilisateurs augmente, vous payez pour le CPU, la RAM et le disque. Si vous avez besoin d'une connexion sociale, d'OAuth2 ou de permissions avancées plus tard, Kratos s'intègre dans l'ensemble de la pile Ory sans nécessiter une réécriture de la plateforme.

L'identité gérée commence à apparaître différemment lorsque vous zoomez sur le déploiement. Ory Kratos se déploie en tant que service natif Docker que vous pouvez exécuter où bon vous semble : sur votre cluster Kubernetes, sur une machine bare-metal ou sur un VPS peu coûteux. Auth0, en revanche, existe principalement en tant que SaaS entièrement géré, avec une infrastructure, un scalabilité et des mises à jour abstraites derrière son tableau de bord et ses API.

Cette séparation est cruciale lorsque vous avez besoin de contrôle. Avec Kratos, votre pile d'authentification se trouve à l'intérieur de votre périmètre réseau, à proximité de votre application et de vos bases de données, intégrée à votre observabilité et à votre CI/CD existants. Auth0 vous offre une console cloud sophistiquée et des SLA, mais vous devez accepter ses régions, son rythme de déploiement et son optimisation des performances opacifiée en échange.

Les modèles de coûts divergent tout aussi nettement. Auth0 facture en fonction des Utilisateurs Actifs Mensuels, limitant les fonctionnalités et les locataires derrière des niveaux d'abonnement qui peuvent augmenter lorsque les inscriptions grimpent ou que des utilisateurs inactifs reviennent brièvement. Kratos est open source : vous payez pour la puissance de calcul, le stockage et le temps d'exploitation, pas par identité.

Pour les produits avec un trafic variable ou saisonnier—pensez aux lancements de jeux, aux plateformes de billetterie ou aux outils éducatifs pendant la période des examens—la tarification MAU se transforme en une taxe de volatilité. Un cluster Kratos auto-hébergé peut fonctionner discrètement avec des ressources minimes et se développer horizontalement en cas de besoin, sans facture surprise liée au comportement des utilisateurs. Vous échangez des factures d'infrastructure prévisibles contre des factures SaaS imprévisibles.

La flexibilité est l'endroit où Kratos s'engage le plus dans son design API-first. Chaque flux—inscription, connexion, récupération, vérification, MFA—expose des API JSON que tout client peut appeler, que ce soit une SPA Next.js, une application mobile native ou une CLI. Les schémas d'identité résident dans la configuration, ce qui vous permet de définir des caractéristiques telles que des identifiants de société, des rôles personnalisés ou des indicateurs de région sans attendre qu'un fournisseur approuve votre cas d'utilisation.

Auth0 réagit avec un immense catalogue d'intégrations et de règles préconstruits, mais ceux-ci s'accompagnent de limites. Vous vous connectez à leurs pages de « connexion universelle », à leurs déclencheurs d'actions, à leur modèle de locataire. Des flux profondément non standards — le profilage progressif, le B2B multi-locataire avec routage personnalisé, ou des politiques complexes par organisation — nécessitent souvent des solutions de contournement ou du code fragile.

Kratos s'intègre dans une pile modulaire : associez-le à Hydra pour OAuth2/OIDC, à Keto pour les permissions, à Oathkeeper en tant que proxy conscient de l'identité, et à Ory Elements pour des composants UI à intégrer facilement. Auth0 regroupe bon nombre de ces fonctionnalités sous une seule marque, mais ce regroupement renforce également la dépendance à un fournisseur. Pour les équipes prêtes à gérer leur infrastructure, Ory Kratos - Documentation se lit moins comme du marketing produit et plus comme un plan pour un système d'authentification qu'elles contrôlent réellement.

Kratos se trouve au centre de quelque chose de plus grand : une pile Ory modulaire qui cherche à décomposer ce que des plateformes comme Auth0 et Okta vendent en tant que boîte opaque. Au lieu d'un monolithe, Ory divise l'identité en services ciblés que vous pouvez exécuter, évoluer et remplacer de manière indépendante. Kratos gère les identités et les sessions, mais il délègue les jetons, les autorisations et l'application en périphérie à ses homologues.

Pour OAuth2 et OpenID Connect, Ory Hydra entre en jeu. Hydra agit en tant que serveur d'autorisation, émettant des jetons d'accès OAuth2 et des jetons ID OIDC que les clients conformes aux normes comprennent déjà. Vous configurez Kratos comme fournisseur de connexion, puis laissez Hydra gérer les flux de consentement, la durée de vie des jetons et les enregistrements des clients sur des charges de travail web, mobile et machine à machine.

L'autorisation granulaire provient de Ory Keto, qui met en œuvre un contrôle d'accès basé sur les relations de style Google Zanzibar. Au lieu de coder en dur des rôles dans la logique de l'application, vous modélisez des relations telles que "l'utilisateur X peut modifier le document Y" et demandez des décisions à Keto. Ce modèle s'adapte des systèmes RBAC simples aux configurations complexes multi-locataires où des milliers de permissions changent chaque minute.

Assis à la frontière, Ory Oathkeeper agit en tant que proxy conscient de l'identité devant vos API et services. Oathkeeper valide les jetons de Hydra, récupère les traits d'identité de Kratos et applique des règles d'accès pouvant déléguer à Keto pour le dernier oui/non. Vous définissez les règles sous forme de configuration, et non de code, ce qui vous permet de mettre à jour les politiques sans redéployer votre application.

Combinez-les et vous obtenez une alternative full-stack aux suites d'entreprise : Kratos pour les identités, Hydra pour OAuth2/OIDC, Keto pour l'autorisation, Oathkeeper en tant que gardien. Chacun fonctionne en tant que conteneur, communique en HTTP/JSON et reste open-source, vous pouvez donc déployer sur matériel nu, Kubernetes ou un simple fichier Docker Compose. Au lieu de payer par utilisateur actif mensuel, vous payez pour l'infrastructure et gardez chaque élément du pipeline d'authentification sous votre contrôle.

Le déploiement d'Ory Kratos à partir de zéro commence avec Docker, et non avec un tableau de bord web. Vous créez un dossier `kratos-demo`, entrez dans un sous-répertoire `docker`, et configurez un `docker-compose.yml` qui récupère l'image officielle Ory Kratos, monte un fichier SQLite local `users.db` et lie un `config/kratos.yml` ainsi qu'un `identity.schema.json`. Après un `docker compose up`, Kratos démarre en mode développement, exposant ses APIs publiques et administratives sur localhost.

Le `docker-compose.yml` reflète en grande partie le quickstart.yml officiel, mais est ajusté pour un ordinateur portable. Le fichier définit `KRATOS_PUBLIC_URL` et `KRATOS_BROWSER_URL` sur `http://localhost:4433` et `http://localhost:4455`, monte le répertoire de configuration et relie un conteneur de serveur de messagerie pour les e-mails de vérification. Les ports restent aux valeurs par défaut—4433 pour le public, 4434 pour l'administrateur—donc tout code client d'exemple provenant de la documentation fonctionne sans modification.

La configuration passe ensuite à deux fichiers principaux : `kratos.yml` et le schéma d'identité JSON. Le schéma d'identité, copié depuis email-password/identity.schema.json, définit un schéma JSON avec des attributs tels que `email`, `first_name`, et `last_name`, ainsi que les informations d'identification du mot de passe. Vous pouvez l'étendre avec des champs personnalisés - identifiants d'entreprise, rôles ou indicateurs de fonctionnalités - sans toucher au cœur de Kratos.

Le fichier `kratos.yml` relie tout ensemble. Vous pointez `selfservice.default_browser_return_url` et les origines autorisées vers votre application Next.js sur `http://localhost:3000`, et vous listez les méthodes HTTP et les en-têtes CORS autorisés. Chaque flux—`login`, `registration`, `recovery`, `verification`, `settings`—dispose d'un `ui_url` qui correspond directement à une route frontend telle que `/auth/login` ou `/auth/register`.

Les secrets et les paramètres d'email se trouvent dans le même fichier YAML. Les configurations de démonstration utilisent des secrets de remplacement, mais les configurations de production doivent faire tourner des clés solides pour `secrets.cookie` et `secrets.cipher`. Les identifiants SMTP configurent le serveur de messagerie afin que Kratos puisse envoyer des liens de vérification et de récupération, qui renvoient ensuite les utilisateurs vers ces mêmes routes `ui_url`.

Sur le frontend, une application Next.js se connecte à Kratos en utilisant `@ory/nextjs` et Ory Elements. Des variables d'environnement comme `NEXT_PUBLIC_KRATOS_PUBLIC_URL=http://localhost:4433` et `KRATOS_BROWSER_URL=http://localhost:4455` sont ajoutées dans `.env.local`, correspondant aux URL Docker. Un petit fichier `ory.config.ts` relie le SDK à ces points de terminaison.

Le middleware de Next.js effectue le travail lourd à l'exécution. Un fichier `middleware.ts` intercepte les requêtes, appelle l'API de session de Kratos, et soit fait passer les utilisateurs authentifiés, soit redirige les visiteurs anonymes vers le processus de connexion géré par Kratos. Avec cela, vous bénéficiez d'un enregistrement complet, d'une connexion, d'une vérification par email et d'écrans MFA fonctionnant sur votre propre infrastructure, et non sur celle d'Okta ou d'Auth0.

Les piles d'identité gérées ont souvent des faiblesses sur le front-end. Soit vous cédez à un boîte de connexion hébergée par un fournisseur, soit vous passez des jours à gérer l'état des formulaires, la validation et la gestion des erreurs pour chaque cas particulier d'authentification. Ory Elements existe précisément pour éliminer cette contrainte.

Au lieu d'expédier un seul widget, Elements est une bibliothèque de composants d'interface utilisateur complète pour React, Next.js (y compris le routeur d'application) et d'autres frameworks modernes. Vous l'installez comme n'importe quel autre package npm, intégrez ses composants dans vos itinéraires et dirigez-les vers votre point de terminaison public Ory Kratos.

L'astuce : Elements ne codifie pas de manière fixe à quoi ressemble un « formulaire de connexion ». Kratos expose chaque flux—connexion, inscription, récupération, paramètres, vérification—sous forme de schéma JSON décrivant les champs, les méthodes, les tokens CSRF et les messages. Elements lit ce schéma à l'exécution et génère automatiquement l'interface utilisateur appropriée.

Accédez à la route de connexion dans l'application de démonstration Next.js et Elements récupère le flux de connexion depuis Kratos, puis construit le formulaire : champ email, champ mot de passe, bouton de soumission, messages de validation, ainsi que tous les traits supplémentaires que vous avez définis dans votre schéma d'identité. Activez l'authentification multi-facteurs ou ajoutez un champ nom d'utilisateur dans Kratos, et l'interface utilisateur rendue se met à jour sans aucune réécriture frontale.

Ce comportement dynamique s'applique à travers les flux. Prêt à l'emploi, Elements peut rendre : - Connexion et inscription - Paramètres du compte et gestion du profil - Récupération de mot de passe et vérification par email - Inscription MFA et écrans de défi

Les développeurs ont un contrôle total sur la présentation. Les composants sont livrés sans style ou légèrement stylés, vous pouvez donc les intégrer dans votre propre mise en page, appliquer Tailwind ou des modules CSS, et personnaliser chaque écran sans réimplémenter la logique. Vous conservez votre système de design tout en externalisant les détails complexes du protocole.

Les économies de temps s'accumulent rapidement. Une équipe typique pourrait passer de 1 à 2 semaines à créer et peaufiner des formulaires d'authentification, puis encore plus de temps à les maintenir à mesure que les exigences changent. Avec Elements, la majeure partie de cela se réduit à la configuration de quelques routes et variables d'environnement, comme le montre la démo de Better Stack.

Pour une personnalisation plus approfondie—comme le changement des traits d'identité, des flux ou des politiques de sécurité—vous ajustez Kratos lui-même. La documentation officielle d'Ory Kratos explique comment ces modifications backend se répercutent automatiquement sur votre interface utilisateur alimentée par Elements.

La sécurité est au cœur d'Ory Kratos, et non ajoutée en tant qu'élément accessoire. Par défaut, Kratos vérifie chaque mot de passe dans l'immense corpus de violations de Have I Been Pwned, rejetant les identifiants déjà apparus dans des fuites réelles. Ce simple contrôle élimine discrètement toute une classe de tentatives de prise de contrôle de comptes qui prospèrent grâce à la réutilisation des mots de passe.

Kratos intègre également la limitation de débit, le renforcement des sessions et la protection CSRF, afin que vous n'ayez pas à les réinventer dans le middleware. Les politiques de mot de passe, les durées de session et l'authentification multi-facteurs se trouvent dans la configuration, et non dispersées dans les contrôleurs et les plugins. Vous bénéficiez d'une posture de sécurité cohérente sur le web, mobile et les clients API, car tout passe par le même moteur API-first.

Au lieu de pratiques « meilleures » ad-hoc, Kratos suit les recommandations du NIST, de l’IETF et des principaux groupes de recherche chez Microsoft et Google. Cela signifie un soutien pour des algorithmes de hachage modernes, des paramètres de sécurité de transport qui privilégient TLS partout, et des flux de connexion qui évitent des anti-modèles tels que des règles de complexité de mot de passe arbitraires. Les responsables du projet citent explicitement les travaux de Troy Hunt et d’autres sur la sécurité utilisable, de sorte que les paramètres par défaut tendent vers « sécurisé et humain », et non « sécurisé et hostile ».

Les équipes de conformité se soucient moins des mots à la mode et plus du contrôle, et Kratos auto-hébergé vous le permet par conception. Les identités des utilisateurs, les sessions et les pistes de vérification résident dans votre propre base de données, dans votre propre région, selon vos propres règles de conservation. Vous choisissez le cloud, le chiffrement au repos, la stratégie de sauvegarde et la gestion des données qui correspondent à votre régulateur, et non à un cluster SaaS partagé d'un fournisseur.

Pour le RGPD, ce contrôle se traduit par des gains concrets. Les contrats de traitement des données deviennent plus simples lorsque vous êtes le processeur, et non simplement un locataire dans le silo d'authentification de quelqu'un d'autre. Le droit à l’effacement, l’exportation des données et la limitation des finalités deviennent des détails de mise en œuvre dans votre propre infrastructure plutôt que des tickets de support à traiter avec un tiers.

Auth0 et Okta peuvent être configurés pour répondre à des normes similaires, mais vous opérez toujours à l'intérieur de leurs limites. Avec Ory Kratos, ces limites sont vos propres politiques, exprimées sous forme de code et de configuration, et auditées avec le reste de votre infrastructure.

L'authentification multi-facteurs signifie généralement jongler avec des SDK, des bibliothèques de codes QR et une interface utilisateur de paramètres personnalisés. Avec Ory Kratos, il vous suffit d'activer quelques options dans un fichier YAML et soudainement, votre application gère le TOTP comme un produit de sécurité expérimenté. Kratos expose l'ensemble du flux 2FA via son API, de sorte que votre backend reste propre et que votre frontend n'ait pas besoin d'une plomberie de sécurité sur mesure.

Activez le TOTP dans la configuration de Kratos et le serveur ajoute immédiatement une nouvelle section "2FA" aux flux d'identité. Lorsqu'un utilisateur s'inscrit, Kratos génère un secret, l'encode en tant qu'URI `otpauth://`, et renvoie une charge utile de code QR prête à être rendue. Votre application ne touche pas directement le secret ; Kratos le stocke et l'encrypte, puis impose une vérification à chaque connexion ultérieure.

La démonstration Next.js de la vidéo montre comment Ory Elements transforme cette capacité backend en un écran de paramètres entièrement géré. Ajoutez les composants Elements dans une route `/settings`, pointez-les vers votre URL publique Kratos, et vous obtenez un tableau de bord utilisateur en direct sans machines d'état React supplémentaires. Les utilisateurs peuvent :

• 1Mettre à jour les traits du profil (email, prénom, nom de famille)
• 2Changer leur mot de passe
• 3Activer ou désactiver l'authentification à deux facteurs basée sur TOTP

Tout cela est expédié par Elements sous forme de composants préconstruits et accessibles qui communiquent avec Kratos via ses flux typés. Vous ne connectez pas des formulaires personnalisés à des points de terminaison aléatoires ; vous générez un modèle de formulaire déclaratif que Kratos définit à l'exécution. Lorsque Kratos ajoute ou modifie un champ, l'interface utilisateur se met à jour automatiquement.

Lors de la configuration de la 2FA, Kratos guide l'utilisateur à travers le scan du code QR et la vérification du premier code. Le serveur valide le TOTP par rapport à son secret enregistré, gère le décalage horaire et marque le deuxième facteur comme actif dans l'enregistrement d'identité. Lorsque les utilisateurs se reconnectent, Kratos élève la session de facteur unique à facteur multiple uniquement après un TOTP valide, et votre application se contente de lire l'état de session résultant.

Cette séparation des préoccupations est essentielle : Kratos gère la génération de QR, le stockage des secrets et la vérification TOTP ; Ory Elements se charge de l'expérience utilisateur. Votre application consomme simplement un pipeline MFA sécurisé et entièrement géré que vous pouvez mettre en place en quelques minutes au lieu de plusieurs semaines.

Les plateformes d'identité gérées continuent d'attirer l'attention des développeurs sur Hacker News, et Ory Kratos apparaît dans ces discussions comme l'option « j'aurais aimé que nous ayons commencé avec cela ». Les commentateurs soulignent constamment son design API-first, ses flux HTTP clairs, et le fait que vous pouvez l'exécuter partout où Docker fonctionne, d'un VPS à 5 $ à Kubernetes. Pour les startups face aux devis d'Auth0 ou d'Okta qui évoluent avec les MAUs, l'attrait est clair : des coûts d'infrastructure prévisibles, pas de taxe par utilisateur, et pas de moteur de règles propriétaire à démêler plus tard.

Kratos s'intègre le mieux lorsque l'authentification est une partie essentielle du produit, et non une simple case à cocher. Les équipes développant des SaaS multi-locataires, des applications sensibles à la confidentialité ou des charges de travail régulées obtiennent un contrôle total sur les données d'identité, les schémas et le cycle de vie. Vous possédez la base de données, vous définissez le schéma d'identité JSON et vous décidez comment intégrer les flux dans vos clients React, Next.js ou natifs via Ory Elements ou votre propre interface utilisateur.

Les projets idéaux partagent généralement quelques caractéristiques : - Besoin de personnalisation approfondie des flux d'inscription, de récupération et de paramètres - Exigences concernant la résidence des données, le RGPD ou l'auditabilité interne - Plan à long terme pour ajouter OAuth2, SSO et des permissions granulaires en utilisant Ory Hydra, Keto et Oathkeeper

Cette architecture modulaire est exactement ce qui séduit les développeurs déçus par les plateformes de « produit d'identité unique ». Vous pouvez commencer avec un email/mot de passe plus TOTP, puis ajouter une connexion sociale ou un SSO d'entreprise plus tard sans tout réécrire. Le Centre de Documentation Ory s'appuie sur cela, avec des guides distincts pour chaque service plutôt qu'un seul assistant de configuration monolithique.

Les compromis sont réels, et les discussions sur Hacker News ne les minimisent pas. Utiliser Kratos signifie posséder des images Docker, de la configuration, des migrations, SMTP, de la surveillance et une réponse aux incidents. Vous remplacez une facture SaaS par une charge opérationnelle : modules Terraform, pipelines CI, agrégation de journaux et rotations d'astreinte.

Les organisations dirigées par des ingénieurs ont tendance à considérer cela comme un échange équitable. Si vous utilisez déjà PostgreSQL, Redis et un maillage de services, ajouter un service Go supplémentaire n'est qu'un bruit, pas un chaos. En revanche, pour une équipe de deux personnes lançant un site marketing avec connexion, un service entièrement géré peut être plus rapide, même si la facture d'Auth0 fait mal plus tard.

Kratos est un choix conscient. Vous achetez la liberté de l'enfermement des fournisseurs au prix de la gestion de votre propre infrastructure d'identité—et pour une part croissante des développeurs, cette offre semble enfin attrayante.

Le contrôle définit l'infrastructure moderne, et Ory Kratos est l'illustration même de ce à quoi ressemble le contrôle sur l'identité. Au lieu de louer votre boîte de connexion auprès d'Auth0 ou d'Okta en espérant que les prix n'exploseront pas avec votre prochaine augmentation de trafic, vous faites fonctionner votre propre serveur d'identité, que vous expédiez dans Docker et intégrez à n'importe quelle pile—Next.js, React, Go, vous l'appelez. L'authentification cesse d'être une boîte noire et redevient du code d'application normal.

Kratos réinvente la dépendance aux SaaS. Vous obtenez un moteur API-first qui gère l'enregistrement, la connexion, la récupération, la vérification par email et l'authentification multi-facteurs, tout en restant indépendant des frameworks UI et frontend. Besoin d'OAuth2, de permissions fines ou d'un proxy conscient de l'identité ? Vous intégrez Hydra, Keto ou Oathkeeper quand vous en avez réellement besoin, au lieu d'acheter une plateforme tout-en-un.

Les changements dans la structure des coûts sont également à prendre en compte. Les factures d'authentification gérées par les utilisateurs actifs mensuels (MAUs) et les fonctionnalités ; une augmentation soudaine de 10 000 à 100 000 utilisateurs peut se transformer en une surprise à cinq chiffres. Kratos est open source, donc vos principaux coûts sont l'informatique, le stockage et le temps d'exploitation, et vous pouvez l'auto-héberger sur tout, d'un VPS à 5 $ à Kubernetes dans plusieurs régions.

L'expérience développeur reste de premier ordre. Ory Elements vous offre des composants React/Next.js préconçus, vous permettant d'avoir des flux de connexion, d'inscription et de paramètres opérationnels en quelques heures, et non en plusieurs semaines. Le fichier Docker Compose de démarrage rapide, le schéma d'identité d'exemple et l'application d'exemple Next.js signifient que vous pouvez passer de zéro à une pile opérationnelle avec vérification par e-mail et 2FA basé sur TOTP en un après-midi.

Il ne s'agit donc pas simplement d'échanger un fournisseur d'authentification contre un autre, mais plutôt de décider qui possède votre couche d'identité. Si vous lancez un nouveau SaaS, refondez un monolithe ou essayez d'échapper aux tarifs excessifs d'Auth0, bloquez une journée et configurez Kratos. Faites l'audit de votre authentification actuelle : prix, dépendance, chemins d'exportation et flexibilité. Ensuite, décidez si votre prochain projet doit s'inscrire dans la feuille de route de quelqu'un d'autre — ou dans la vôtre.

Qu'est-ce qu'Ory Kratos ?

Ory Kratos est un serveur de gestion d'identité et d'utilisateur open-source, axé sur l'API. Il gère les flux d'authentification essentiels tels que l'inscription, la connexion, l'authentification multifactorielle (MFA) et la récupération de compte, permettant aux développeurs de s'auto-héberger et de conserver un contrôle total sur leur infrastructure d'authentification.

Ory Kratos est-il entièrement gratuit ?

Oui, le logiciel principal Ory Kratos est open-source et gratuit à auto-héberger. Ory propose également une licence d'entreprise payante et un service cloud géré (Ory Network) qui offrent des fonctionnalités supplémentaires telles que la haute disponibilité, des SLA et un support dédié.

Comment Ory Kratos se compare-t-il à Auth0 ?

Kratos offre une plus grande flexibilité, contrôle et rentabilité grâce à son modèle auto-hébergé et open-source. Auth0 est un service entièrement géré qui permet une configuration plus rapide et propose de nombreuses intégrations préconstruites, mais entraîne un verrouillage par le fournisseur et des coûts potentiellement plus élevés.

Puis-je migrer mes utilisateurs existants d'Auth0 vers Ory Kratos ?

Oui, Ory fournit de la documentation et des guides sur la manière de migrer une base d'utilisateurs existante depuis des plateformes comme Auth0 vers Kratos, permettant ainsi une transition plus fluide.