Quelle solution d’auth open source choisir sur Kubernetes ?

Le marché de l’auth adore brouiller les pistes.

On te vend du “open source” en mélangeant produit OSS, options enterprise, confort du cloud managé et documentation opportunément floue.

Résultat, beaucoup de comparatifs ne servent à rien. Ils comparent des cases cochées sur une landing page, pas ce que tu peux vraiment déployer, opérer et défendre en self-hosted.

Et c’est précisément là que le sujet devient sérieux.

Quand tu choisis une brique d’auth pour un produit Kubernetes auto-hébergé, tu ne choisis pas juste un login. Tu choisis une dette d’exploitation, une posture de sécurité, une trajectoire produit, et parfois une future migration douloureuse.

Donc non, la bonne question n’est pas “qui a le plus de features ?”.

La bonne question, c’est:

**quelle solution tient vraiment la route en open source self-hosted, avec de vraies exigences de sécurité et d’exploitation ?**

Dans cet article, je regarde volontairement un périmètre strict:

• ce qui est **réellement disponible en OSS**
• ce qui est **documenté en self-hosted**
• ce qui est **crédible sur Kubernetes**
• et ce qui ne demande pas de reconstruire la moitié du produit autour

Je me base sur les docs primaires des produits, mais aussi sur un cadre sécurité simple:

• **NIST** (*National Institute of Standards and Technology*)
• **CISA** (*Cybersecurity and Infrastructure Security Agency*)
• **OWASP** (*Open Worldwide Application Security Project*)

Le cadre de survie

Avant de comparer les produits, voilà ce qu’une solution d’auth sérieuse doit couvrir.

Je le résume volontairement.

1. Du MFA résistant au phishing

Pas juste “on supporte TOTP”.

Le vrai niveau attendu aujourd’hui, c’est **WebAuthn / passkeys / FIDO2**.

Le NIST rappelle qu’à **AAL2** (*Authentication Assurance Level 2*), il faut au moins une option résistante au phishing, et qu’à **AAL3** (*Authentication Assurance Level 3*), les exigences cryptographiques montent encore.

En clair: si ton produit s’arrête à mot de passe + OTP, tu es déjà en retard.

2. Une politique mot de passe moderne

Pas de folklore du style “1 majuscule, 1 symbole, rotation tous les 90 jours”.

On veut:

• mots de passe longs
• passphrases acceptées
• blocage des secrets compromis
• stockage robuste
• pas de règles absurdes qui dégradent l’UX sans améliorer la sécurité

3. Une vraie gestion de session

Le login ne suffit pas.

Une bonne solution doit gérer proprement:

• rotation de session
• révocation de tokens
• timeouts d’inactivité
• timeouts absolus
• inventaire de sessions ou devices
• réauthentification sur changement de privilège

4. Une réauthentification sur les actions sensibles

Changer un email, désactiver un facteur MFA, ajouter un nouvel authenticator ou accéder à l’admin ne devrait jamais reposer sur une confiance implicite héritée d’un vieux login.

5. Un recovery propre

Le vrai point faible est souvent là.

Si le reset password, le changement d’email ou la récupération après perte de device sont faibles, le reste ne sert à rien.

6. De l’audit exploitable

Pas du log verbeux pour faire joli.

On veut des événements utiles pour:

• sécurité
• investigation
• conformité
• opérations admin

7. Des garde-fous anti-abus

Une solution sérieuse doit savoir gérer:

• brute force
• credential stuffing
• enumeration
• abus de recovery
• MFA fatigue
• automatisation

8. Des standards propres

On veut parler à autre chose qu’à une démo locale.

Donc au minimum:

• **OIDC** (*OpenID Connect*)
• **OAuth 2.0**
• **SAML** (*Security Assertion Markup Language*) si besoin entreprise
• **SSO** (*Single Sign-On*) quand le contexte l’exige
• **WebAuthn / FIDO2**
• et idéalement **SCIM** si le provisioning compte

La matrice de vérité

C’est la synthèse que la plupart des lecteurs viennent chercher.

Important: elle porte sur ce qui semble **réellement disponible ou documenté** dans les versions open source et auto-hébergées, pas sur les variantes cloud ou enterprise.

**Lecture rapide**

• **Fort**: capacité bien présente et crédible en OSS self-hosted
• **Moyen**: possible, mais partiel, plus custom, ou moins structurant
• **Faible**: pas au niveau attendu pour un socle IAM sérieux
• **À vérifier**: périmètre OSS/commercial ou maturité trop flous pour être affirmatif sans réserve

Zitadel

**MFA phishing-resistant OSS**: Fort

**Session / révocation**: Fort

**Recovery / enrôlement**: Fort

**Audit / traçabilité**: Fort

**Standards / intégration**: Fort

**Multi-tenant / B2B OSS**: Fort

**Self-hosted K8s OSS**: Fort

**Verdict**: Le plus cohérent en OSS pour un vrai socle IAM moderne.

---

Keycloak

**MFA phishing-resistant OSS**: Fort

**Session / révocation**: Fort

**Recovery / enrôlement**: Fort

**Audit / traçabilité**: Moyen à Fort

**Standards / intégration**: Fort

**Multi-tenant / B2B OSS**: Moyen à Fort

**Self-hosted K8s OSS**: Fort

**Verdict**: Très solide en OSS, mais plus lourd à opérer.

---

Ory Kratos + Hydra

**MFA phishing-resistant OSS**: Fort

**Session / révocation**: Moyen à Fort

**Recovery / enrôlement**: Moyen

**Audit / traçabilité**: Moyen

**Standards / intégration**: Fort

**Multi-tenant / B2B OSS**: Faible à Moyen

**Self-hosted K8s OSS**: Fort

**Verdict**: Puissant, mais plus d’assemblage que de produit fini.

---

Hanko OSS

**MFA phishing-resistant OSS**: Fort

**Session / révocation**: Moyen

**Recovery / enrôlement**: Moyen

**Audit / traçabilité**: Moyen

**Standards / intégration**: Moyen à Fort

**Multi-tenant / B2B OSS**: À vérifier / limité

**Self-hosted K8s OSS**: Moyen

**Verdict**: Très bon angle passkeys, moins convaincant comme IAM large.

---

SuperTokens OSS

**MFA phishing-resistant OSS**: Moyen

**Session / révocation**: Moyen

**Recovery / enrôlement**: Moyen

**Audit / traçabilité**: Moyen

**Standards / intégration**: Moyen

**Multi-tenant / B2B OSS**: Moyen, sous réserve licence et périmètre

**Self-hosted K8s OSS**: Moyen

**Verdict**: Bon moteur auth applicatif, moins fort comme IAM complet.

---

Supabase Auth OSS

**MFA phishing-resistant OSS**: Faible à Moyen

**Session / révocation**: Moyen

**Recovery / enrôlement**: Moyen

**Audit / traçabilité**: Faible à Moyen

**Standards / intégration**: Moyen

**Multi-tenant / B2B OSS**: Faible

**Self-hosted K8s OSS**: Moyen

**Verdict**: Bien pour un BaaS, moins pour un vrai socle IAM.

Le deep dive qui compte vraiment

Zitadel, le choix de la raison

Zitadel est dans une zone rare du marché.

Il coche une grosse partie des besoins IAM modernes **dans le périmètre OSS lui-même**, sans t’imposer la lourdeur d’un Keycloak ni le puzzle d’un Ory.

C’est la différence entre une plateforme que tu peux défendre en comité d’architecture, et une stack que tu vas finir par justifier à coups de slides.

Côté OSS self-hosted, on retrouve un ensemble cohérent:

• OIDC, OAuth2, SAML
• passkeys, WebAuthn, U2F, OTP
• organisations et logique multi-tenant
• audit trail sérieux
• self-service et extensibilité
• Helm chart et déploiement documenté

Sur Kubernetes, il a un autre avantage: son approche est beaucoup plus **database-first** que “stateful app bizarre à apprivoiser”.

Autrement dit, tu gères surtout correctement ta base et ton déploiement, au lieu d’entrer dans une logique de cluster applicatif compliqué à stabiliser.

> ✅ **Green Flag Zitadel**: tu récupères dans l’OSS l’essentiel de ce qui rend une plateforme IAM exploitable en prod, sans reconstruire toi-même la moitié du produit.

> ⚠️ **Red Flag Zitadel**: si ton organisation a déjà un historique lourd autour de Keycloak, de SAML legacy ou de workflows maison très spécifiques, la migration mentale et technique peut quand même coûter cher.

Keycloak, le choix du legacy puissant

Keycloak reste une machine de guerre.

En OSS, le périmètre est massif. OIDC, OAuth2, SAML, WebAuthn, MFA, recovery, usages enterprise, écosystème connu, docs abondantes: tout le monde ou presque l’a déjà croisé.

Le problème, ce n’est pas ce qu’il sait faire.

Le problème, c’est ce qu’il te demande de porter.

Choisir Keycloak en 2026, c’est souvent accepter une plateforme puissante mais lourde, avec une JVM qui veut son attention, des ressources non négligeables, et une complexité d’exploitation qui dépasse vite le besoin réel.

Dit autrement: c’est rarement un mauvais choix technique. C’est souvent un choix plus cher qu’on ne l’admet au départ.

> ✅ **Green Flag Keycloak**: si tu veux une couverture fonctionnelle immense et une solution OSS déjà connue de la plupart des équipes IAM, c’est une valeur sûre.

> ⚠️ **Red Flag Keycloak**: tu ne choisis pas juste une solution auth. Tu choisis aussi une JVM capricieuse, du tuning, et une usine qui peut finir par consommer un vrai budget d’attention ops.

Ory, le choix du sur-mesure et de la sueur

Ory plaît beaucoup aux équipes qui aiment les approches headless, API-first et composables.

Et il y a une vraie noblesse technique dans cette approche.

Kratos pour l’identité, Hydra pour OAuth2/OIDC, une philosophie modulaire, du contrôle fin sur les parcours: sur le papier, c’est séduisant.

Mais ce qu’on oublie souvent de dire, c’est qu’Ory te livre surtout un **kit de construction**, pas un produit fini.

Et pour beaucoup d’équipes, le deal breaker commence ici: **Kratos ne fournit pas d’UI native clé en main en OSS**. Si tu veux une expérience login cohérente, il faut la construire, l’intégrer, la maintenir, et la faire évoluer.

C’est parfaitement défendable si tu assumes ce choix.

C’est beaucoup moins amusant quand tu pensais acheter du temps et que tu récupères surtout du backlog.

> ✅ **Green Flag Ory**: architecture propre, API-first, très bonne composabilité, bon choix si tu veux contrôler finement l’expérience et les flows.

> ⚠️ **Red Flag Ory**: plus de composants, plus d’assemblage, plus de corrélation, plus d’UX à fabriquer. Si tu veux un IAM “prêt à l’emploi”, ce n’est probablement pas le bon cheval.

Hanko, le choix passkey-first

Hanko ne joue pas exactement la même partie.

Son angle fort, c’est l’auth moderne, passwordless, orientée passkeys.

Et franchement, c’est intelligent. Parce qu’on sait déjà que rester bloqué sur le mot de passe comme centre du monde n’est pas une stratégie d’avenir.

Là où Hanko est intéressant, c’est quand ton sujet principal est:

• une UX moderne
• du passwordless crédible
• une surface produit plus ciblée
• un besoin moins “IAM enterprise complet” et plus “auth contemporaine bien pensée”

Là où il faut rester lucide, c’est sur la profondeur du produit hors de ce cœur-là.

Multi-tenant avancé, gouvernance B2B, audit structurant, exploitation Kubernetes à grande échelle: aujourd’hui, le niveau de confiance n’est pas le même que sur Zitadel ou Keycloak.

> ✅ **Green Flag Hanko**: excellent candidat si ton vrai pari, c’est le passkey-first en open source avec une UX plus moderne que les stacks historiques.

> ⚠️ **Red Flag Hanko**: très intéressant comme spécialiste. Moins rassurant comme socle IAM large pour un produit B2B exigeant.

SuperTokens, le choix frontend-first avec un vrai sujet de licence

SuperTokens séduit vite les équipes produit.

Et c’est normal.

L’intégration est agréable, les SDKs sont nombreux, l’expérience côté développeurs web est bonne, et l’outil donne le sentiment de reprendre la main sans se noyer dans un IAM trop institutionnel.

Comme moteur d’auth applicatif, il est crédible.

Mais il faut être adulte sur deux sujets.

Le premier, c’est le périmètre.

SuperTokens n’est pas, dans mon arbitrage, un équivalent direct de Zitadel ou Keycloak pour un socle IAM OSS complet, multi-tenant, gouvernable et compliance-friendly.

Le second, c’est la **licence SSPL**.

Et ça, pour une entreprise, un produit commercialisé, ou un contexte self-hosted vendu à des clients, ce n’est pas une note de bas de page. C’est un sujet de gouvernance.

> ✅ **Green Flag SuperTokens**: très bonne DX, très bon choix si tu veux une auth applicative moderne et rapide à intégrer dans une stack web.

> ⚠️ **Red Flag SuperTokens**: la licence SSPL et le positionnement moins IAM que product auth peuvent suffire à l’écarter dans beaucoup de contextes B2B ou commerciaux.

Supabase Auth, le choix du confort, mais pas forcément le bon combat

Supabase est excellent pour aller vite.

C’est le choix du confort.

Mais si tu n’utilises que l’auth, c’est parfois comme acheter un porte-avions pour faire de la pêche à la ligne.

Le sujet n’est pas que Supabase soit mauvais. Le sujet, c’est qu’il répond souvent à une question plus large: backend, base de données, storage, auth, fonctions, outillage dev.

Si c’est bien ton besoin, très bien.

Mais si ton sujet principal est une **vraie fondation IAM self-hosted OSS**, l’histoire devient beaucoup moins convaincante.

En self-hosted, l’expérience est aussi nettement moins magique que le cloud. Plus de composants, plus de variables d’environnement, plus de dépendances, plus de plomberie.

> ✅ **Green Flag Supabase**: excellent si ton besoin réel est un backend moderne avec auth intégrée, et que l’auth n’est qu’un composant du tout.

> ⚠️ **Red Flag Supabase**: en OSS self-hosted pur, si tu veux surtout une plateforme auth sérieuse, tu embarques beaucoup d’écosystème pour un besoin plus étroit.

Mon arbitrage final

Si je regarde strictement le prisme **open source + self-hosted + Kubernetes + exigences de sécurité réelles**, mon classement est simple:

1. **Zitadel**

2. **Keycloak**

3. **Ory**

4. **Hanko** si l’axe principal est le passkey-first

5. **SuperTokens** si le sujet est surtout l’auth applicative web, avec vigilance licence

6. **Supabase Auth** si l’auth n’est qu’une brique d’un backend plus large

Ce qu’il faut retenir

Le meilleur outil n’est pas celui qui a le plus de cases cochées sur une landing page.

C’est celui qui met réellement, dans sa version open source et auto-hébergeable, les briques dont tu as besoin sans te refiler discrètement la moitié du travail.

Et à ce jeu-là, **Zitadel est aujourd’hui la solution la plus équilibrée** pour beaucoup d’équipes qui veulent:

• une base IAM moderne
• du multi-tenant natif
• une posture sécurité sérieuse
• une exploitation Kubernetes raisonnable
• une trajectoire plus propre qu’un assemblage maison
• moins de lourdeur structurelle qu’un Keycloak classique

**Keycloak** reste la référence lourde mais complète.

**Ory** reste le choix du contrôle maximal, avec la sueur qui va avec.

**Hanko** est une option intéressante si ton axe est vraiment le passwordless moderne.

**SuperTokens** est fort pour l’auth applicative, mais moins convaincant comme plateforme IAM globale, et la licence compte vraiment.

**Supabase Auth** est utile dans un écosystème Supabase. Beaucoup moins comme fondation IAM de référence.

Et vous ?

Quel est le vrai **deal breaker** qui vous a déjà fait écarter, ou abandonner, une stack d’auth en production ? Le coût ops ? La licence ? L’absence de passkeys ? Le self-hosted trop fragile ?

Références

Exigences sécurité

• NIST SP 800-63B: https://pages.nist.gov/800-63-4/sp800-63b.html
• NIST AAL guidance: https://pages.nist.gov/800-63-4/sp800-63b/aal/
• NIST supplement on syncable authenticators / passkeys: https://www.nist.gov/publications/incorporating-syncable-authenticators-nist-sp-800-63b
• OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• OWASP Session Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• CISA MFA: https://www.cisa.gov/mfa
• CISA phishing-resistant MFA fact sheet: https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf

Sources produit primaires

• ZITADEL docs: https://zitadel.com/docs/
• ZITADEL features: https://zitadel.com/docs/concepts/features
• ZITADEL features overview: https://zitadel.com/features
• SuperTokens self-hosting: https://supertokens.com/docs/deployment/self-host-supertokens
• SuperTokens multi-tenancy docs: https://supertokens.com/docs/multi-tenancy/introduction
• Hanko docs: https://docs.hanko.io/
• Hanko intro: https://docs.hanko.io/introduction
• Hanko enterprise SSO guide: https://docs.hanko.io/guides/enterprise-sso/introduction
• Ory Kratos overview: https://www.ory.sh/kratos
• Ory passkeys: https://www.ory.sh/passkeys/
• Keycloak server admin docs: https://www.keycloak.org/docs/latest/server_admin/
• Keycloak features: https://www.keycloak.org/server/features
• Supabase Auth docs: https://supabase.com/docs/guides/auth
• Supabase self-hosted auth: https://supabase.com/docs/reference/self-hosting-auth/introduction
• Supabase self-hosting: https://supabase.com/docs/guides/self-hosting