Est-ce un remplaçant direct de Keycloak ?
Non. Keycloak est un serveur d'identité généraliste avec SAML, fédération LDAP, pages de connexion personnalisables et console d'administration. Nautilus fait un travail plus étroit : la connexion et les comptes utilisateurs pour les clients d'un produit SaaS, derrière une API HTTP sans écrans propres. Si vous avez besoin de SAML ou d'authentification unique pour des clients d'entreprise, gardez Keycloak. Si vous l'utilisez pour la connexion par mot de passe, Google et GitHub, la récupération, la double authentification et les rôles au sein des organisations de vos clients, c'est la partie que vous pouvez cesser d'héberger. Les organisations, les rôles et les membres se gèrent par l'API, et le tableau de bord n'a pas encore d'écran pour les membres. Les rôles d'un utilisateur reviennent dans le jeton signé, dans l'introspection du jeton et dans la vérification de session.
Dois-je encore construire des écrans de connexion ?
Oui, les écrans. Nautilus renvoie chaque étape sous forme de réponse d'API et votre code envoie ce que l'utilisateur a saisi : les formulaires ressemblent au reste de votre produit. Ce que vous cessez de construire, c'est tout ce qu'il y a derrière : stockage des mots de passe, e-mails de récupération et de vérification, sessions, connexions par fournisseur. Si vous voulez une page de connexion hébergée et personnalisable, Keycloak en a une et ceci n'en a pas.
Comment vérifier un webhook ?
Chaque livraison porte les en-têtes svix-id, svix-timestamp et svix-signature : une signature HMAC-SHA256 calculée sur l'identifiant, l'horodatage et le corps brut. Vérifiez-la avec la bibliothèque Svix officielle et open source, qui existe pour Node, Python, Go, Rust, PHP, Java, Ruby, C# et Kotlin, plutôt que d'écrire la vérification vous-même. Les livraisons échouées sont retentées et peuvent être renvoyées depuis le tableau de bord.
Combien ça coûte ?
Gratuit jusqu'à 1 000 utilisateurs actifs par mois, sans carte bancaire. Un utilisateur actif est une personne qui se connecte au moins une fois dans un mois calendaire, quel que soit le nombre de fois ; les personnes que vous créez par l'API et qui ne se connectent jamais ne sont pas comptées. Pro coûte 99 € par mois pour 10 000 utilisateurs actifs et Advanced 199 € pour 50 000. Les rôles et les organisations sont dans toutes les offres, Free comprise, et le journal d'audit est conservé 7, 30 ou 90 jours selon l'offre ; ni l'un ni l'autre n'est une option avec son propre prix. Au-delà de votre limite, la connexion n'est jamais bloquée : nous vous écrivons à 80 % et à 100 %, et vous avez le temps de passer à l'offre supérieure avant que les nouvelles inscriptions soient refusées. La liste à jour est sur la page des tarifs.
Qu'est-ce qui tourne en dessous ?
Ory Kratos, le serveur d'identité open source, en un seul déploiement partagé pour tous les comptes. Le tableau de bord, les clés d'API, les webhooks, les organisations et les rôles, les jetons signés et le contrôle qui tient les utilisateurs d'un compte à l'écart de ceux d'un autre sont les nôtres, par-dessus. Le prix du partage : le schéma utilisateur est fixé à un e-mail, une langue et votre champ JSON, et vous ne pouvez pas modifier la configuration propre de Kratos. Le moteur est ouvert : si cela ne suffit plus, le même logiciel tourne sur vos propres serveurs. La couche que nous avons construite par-dessus ne vous suit pas. Pour migrer ailleurs, demandez au support un export de tous vos utilisateurs avec leurs hachages de mot de passe, leurs comptes sociaux liés, leurs métadonnées, leurs organisations et leurs rôles : vous recevez un fichier chiffré sous 7 jours, dans un format que notre propre import accepte et qui correspond à Ory Kratos.
Où sont stockées les données d'identité ?
Les identités, les sessions et vos métadonnées personnalisées sont stockées dans des bases de données sur nos propres serveurs en France, chez OVHcloud. Les e-mails sortants, comme les codes de connexion et de récupération, sont remis par Resend, un prestataire américain, dans le cadre des clauses contractuelles types de la Commission européenne.
Comment fonctionnent les rôles et les contrôles de permission ?
Vous créez une organisation, vous y définissez des rôles (un rôle est un nom et une liste de permissions comme invoices:write), puis vous ajoutez un utilisateur à l'organisation avec un rôle. Pour vérifier, appelez authorize avec l'utilisateur, la permission et l'organisation : vous obtenez autorisé ou non, avec une raison et le rôle. Ou lisez les rôles dans le jeton signé et laissez votre politique de base de données décider. Les permissions sont comparées exactement, sans jokers. Un rôle que quelqu'un détient ne peut pas être supprimé tant que cette personne n'a pas été déplacée. Une appartenance peut porter une échéance et être retirée par une règle quand elle passe. Chaque changement de rôle ou d'appartenance figure dans le journal d'audit.
Que ne fait-il pas ?
Pas de SAML ni d'authentification unique d'entreprise, pas de page de connexion hébergée, pas de composants prêts à l'emploi, pas de passkeys, pas de codes SMS et pas de Sign in with Apple. Ce n'est pas un fournisseur OAuth ou OpenID pour des tiers : le jeton signé est fait pour être vérifié, et Nautilus n'a pas de point d'autorisation. Les e-mails que nous envoyons pour vous partent de l'adresse de Verne et sont rédigés dans la langue de l'utilisateur (six langues, d'après son locale). Les SDK officiels couvrent Node, Python, PHP et Rust.
Comment se compare-t-il à Auth0, Clerk, Ory Network ou Logto ?
Il y a une page pour chacun, avec leurs prix tirés de leurs propres sites et la date de notre relevé. En bref : ils sont en avance sur les écrans prêts à l'emploi, l'authentification unique d'entreprise et le nombre de méthodes de connexion. Nous sommes en avance sur les règles qui suppriment les comptes inutilisés, sur les rôles et les organisations sans prix à part et, face à Clerk, sur l'endroit où se trouvent les données. Lisez les pages, puis décidez. Les pages sont en anglais.