Keycloak, authentik ou Zitadel : quel SSO sur VPS ?

Quel serveur SSO choisir pour un VPS

Keycloak, authentik et Zitadel sont les serveurs d’authentification unique (SSO) auto-hébergés auxquels on pense dès qu’il faut utiliser un seul compte pour toutes les applications d’un serveur. Sur un petit VPS, ils ne sont pas interchangeables. authentik est le choix par défaut le plus sûr pour un serveur qui héberge trois ou quatre applications auto-hébergées, car c’est le seul des trois à pouvoir placer une page de connexion devant une application qui n’en possède pas. Keycloak convient lorsque toutes les applications à protéger prennent déjà en charge un protocole standard et que vous pouvez consacrer suffisamment de mémoire à une machine virtuelle Java (JVM). Zitadel est conçu pour les développeurs qui publient un produit via une API ; c’est celui que je n’essaierais pas d’exécuter avec moins de 4 GB de mémoire.

Commencez par choisir, puis installez. Une fois votre choix effectué, l’installation pratique d’authentik sur un VPS détaille la configuration étape par étape.

De quelle quantité de RAM chacun a-t-il réellement besoin ?

Commencez par le seuil de ressources, car il détermine la liste restreinte avant toute fonctionnalité. Les chiffres ci-dessous proviennent des données publiées par chaque projet, consultées en octobre 2026. Il s’agit de recommandations des éditeurs, et non de résultats issus d’un load test.

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

La page d’installation d’authentik avec Docker Compose demande « un hôte avec au moins 2 cœurs CPU et 2 GB de RAM », soit 2048 MB, et son fichier compose publié lance 3 conteneurs : PostgreSQL, le serveur et le worker. Cette valeur pour l’hôte doit couvrir les trois, base de données comprise.

Keycloak publie la valeur la plus précise des 3. Son guide de dimensionnement indique que « l’utilisation mémoire de base pour un Pod, caches des données des realms et 10 000 sessions en cache compris, est de 1250 MB de RAM ». Ces 1250 MB correspondent au serveur Keycloak avec ces caches. Le guide dimensionne la base de données séparément : PostgreSQL a donc besoin de mémoire en plus. La même page explique pourquoi la limite mémoire du conteneur est si importante : Keycloak utilise 70 % de la limite mémoire pour le heap et environ 300 MB de mémoire non-heap supplémentaires. Dans son exemple, la valeur de base de 1250 MB devient une limite mémoire de 1360 MB. Avec 1 GB attribué au conteneur, il calcule un heap d’environ 717 MB. Les quelque 300 MB de mémoire non-heap portent alors le total à environ 1017 MB. Il reste donc très peu de marge sous la limite, alors que la valeur de base du guide, avec les caches des realms et 10 000 sessions, est de 1250 MB.

La page compose de Zitadel demande également 2 GB, soit les mêmes 2048 MB, comme prérequis pour l’ensemble du guide, du quickstart jusqu’à l’étape homelab ou semi-production. Pour un dimensionnement supérieur, consultez sa page consacrée à la production. Le processus Zitadel lui-même a besoin d’« environ 512MB de RAM et peut fonctionner avec moins d’un cœur CPU ». La base de données est la partie la plus coûteuse : « environ un cœur CPU pour 100 requêtes par seconde (req/s) et 4GB de RAM par cœur ». Le hachage des mots de passe demande ensuite « 4 cœurs CPU disponibles à cette fin », car un pic de connexions se transforme en pointe d’utilisation CPU. Le compose officiel v4 lance 4 conteneurs avant tout ajout : Traefik comme proxy, l’API Zitadel, un conteneur Login UI séparé et PostgreSQL. Redis et un collecteur OpenTelemetry sont placés derrière des profils compose optionnels.

Keycloak et authentik tiennent donc sur un VPS de 4 GB, avec encore de la marge pour les applications que vous protégez. Zitadel démarre avec 2 GB, puis entre en concurrence avec son propre PostgreSQL pour la mémoire à chaque connexion. Je ne ferais pas fonctionner Zitadel avec moins de 4 GB. Sur une machine qui héberge également des applications, je prévoirais 8 GB.

Ce que chaque solution exécute réellement sur votre serveur

authentik utilise PostgreSQL et deux instances d’une même image : un serveur et un worker. Le serveur répond aux requêtes HTTP et héberge un outpost intégré. Le worker exécute les tâches en arrière-plan, comme la synchronisation des annuaires et l’envoi des e-mails. L’installation publiée est courte.

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

Le serveur publie les ports 9000 et 9443. La première visite du port 9000 lance l’assistant de configuration initiale, qui permet de définir le mot de passe de l’utilisateur akadmin par défaut. Placez un reverse proxy avec un certificat valide devant ce service avant de rendre ce port accessible depuis Internet.

Keycloak consiste en un processus et une base de données que vous fournissez. Le démarrage rapide utilise un seul conteneur.

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.8.1 start-dev

start-dev sert à explorer l’interface. Il utilise une base de données locale de développement et aucun TLS (transport layer security). Un conteneur démarré de cette façon puis supprimé emporte donc votre realm avec lui. En production, utilisez plutôt start, avec un PostgreSQL réel via KC_DB et un hostname public via KC_HOSTNAME. Le guide de production de Keycloak précise également que toutes les communications avec le serveur doivent utiliser un canal sécurisé. HTTPS n’est donc pas facultatif dans ce contexte.

Zitadel est la stack à quatre conteneurs décrite plus haut.

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

Définissez ZITADEL_MASTERKEY dans .env avant le premier démarrage. Il s’agit de la clé de 32 caractères que Zitadel utilise pour chiffrer les secrets dans la base de données. Si vous la perdez, vous perdez l’accès à ces secrets. Si vous débutez avec ce type de stack, les bases de Docker Compose pour un VPS expliquent les choix de volume et de restart policy qui déterminent si votre fournisseur d’identité survivra à un redémarrage.

Quels protocoles chacun prend-il en charge ?

Les trois prennent en charge OpenID Connect (OIDC), la couche d’authentification construite au-dessus d’OAuth 2.0 qu’utilisent les applications modernes. Les trois prennent également en charge SAML 2.0 (security assertion markup language), l’ancien standard encore utilisé par les logiciels d’entreprise. La différence principale concerne LDAP (lightweight directory access protocol), qui recouvre deux fonctions opposées.

Lire depuis LDAP signifie que le serveur SSO vérifie les mots de passe dans un annuaire que vous exploitez déjà. Keycloak le fait via la fédération d’utilisateurs. Zitadel le permet également : sa documentation explique comment « connecter un serveur LDAP comme fournisseur d’identité dans ZITADEL ».

Fournir un service LDAP signifie qu’une application qui ne parle que LDAP peut effectuer une liaison auprès de votre serveur SSO comme s’il s’agissait de l’annuaire. Seul authentik prend cette fonction en charge. Son fournisseur LDAP rend « tous les utilisateurs et groupes de la base de données d’authentik consultables via l’annuaire LDAP » au moyen d’un LDAP outpost dédié, avec LDAPS disponible sur le port 636. Par défaut, un utilisateur ayant effectué une liaison ne peut consulter que ses propres informations et ses groupes. Le compte de service utilisé par l’application pour effectuer la liaison doit donc disposer de l’autorisation « Search full LDAP directory » pour voir tous les utilisateurs. Sa documentation couvre uniquement les opérations de liaison et de recherche et ne décrit aucune opération d’écriture. Considérez-le donc comme un annuaire en lecture seule. Un code à usage unique est ajouté au mot de passe après un point-virgule, comme dans password;123456. Les authentificateurs SMS ne sont pas pris en charge lors de la liaison.

Si l’une des applications de votre liste ne parle que LDAP, la comparaison s’arrête là. Keycloak et Zitadel ne peuvent pas répondre à cette liaison. Vous devrez donc exécuter un second annuaire à côté d’eux et synchroniser les deux listes d’utilisateurs.

Qu’en est-il des applications sans aucune authentification ?

Le « forward auth » est la solution, et c’est un cas de figure récurrent sur un serveur auto-hébergé. Votre reverse proxy demande au serveur SSO si une requête est autorisée avant de la transmettre au backend. L’application située derrière n’a pas connaissance du SSO. Elle reçoit des requêtes déjà vérifiées par le proxy, généralement avec le nom d’utilisateur dans un en-tête.

Le fournisseur de proxy d’authentik couvre ce besoin avec trois modes documentés. « Proxy » permet à l’outpost authentik de transmettre lui-même le trafic à l’application en amont. « Forward auth (single application) » laisse le trafic à votre reverse proxy existant et n’utilise authentik que pour la vérification de l’authentification. « Forward auth (domain level) » protège toutes les applications sous un domaine parent avec un seul fournisseur. Le mode « domain level » est le plus pratique, mais il comporte une limite documentée : il « ne peut pas appliquer des règles d’autorisation différentes par application », donc toutes les applications sous ce domaine partagent le même ensemble de politiques.

Keycloak ne propose rien de tel. Son proxy compagnon, Keycloak Gatekeeper, a été renommé Louketo Proxy, a atteint sa fin de vie en novembre 2020 et a été archivé sur GitHub en décembre 2020. Pour protéger une application sans support OIDC, vous devez exécuter un composant séparé devant elle, généralement oauth2-proxy, pointé vers un client Keycloak. Zitadel ne possède pas non plus de mode « forward auth » natif ; la solution consiste donc à installer, surveiller et mettre à jour ce composant supplémentaire.

Ce saut supplémentaire est le point où la configuration du reverse proxy cesse d’être simple. Lisez donc comment Traefik expose plusieurs applications Docker Compose avant d’y intégrer un middleware d’authentification.

Quel est le niveau de difficulté des mises à niveau ?

Au 25 octobre 2026, les versions actuelles sont Keycloak 26.8.1, authentik 2026.8.5 et Zitadel v4.20.0. Les trois exécutent des migrations de schéma sur PostgreSQL. Chaque mise à niveau modifie donc la base de données. Sauvegardez d’abord la base de données, à chaque fois. Cette habitude vaut plus que n’importe quelle fonctionnalité présentée dans cette comparaison.

authentik applique la règle la plus stricte et l’énonce clairement : « Les mises à niveau doivent suivre la séquence des versions majeures ; ne passez pas directement d’une ancienne version majeure à la version la plus récente. » Passez à la dernière version corrective de chaque version avant de passer à la suivante, et « authentik ne prend pas en charge les rétrogradations ». Avec un projet versionné selon l’année civile, un retard d’un an transforme une mise à niveau en une chaîne de mises à niveau, chacune avec sa propre migration de base de données.

Le guide de mise à niveau de Keycloak indique l’ordre à suivre : examinez les changements de migration depuis la version précédente, mettez à niveau le serveur, puis mettez à niveau les adapters. La migration de la base de données s’exécute automatiquement. Vous pouvez aussi l’exporter et l’appliquer manuellement, ce qui est utile si vous voulez examiner les changements avant leur application. Avec Keycloak, le coût vient de cette lecture. Les notes de version contiennent des fonctionnalités dépréciées et des changements de comportement qu’il est facile de passer sous silence et coûteux de manquer.

Zitadel sépare ses phases init et setup du serveur en fonctionnement. Sa documentation destinée à la production recommande de les conserver séparées afin que la mise à l’échelle ne répète pas l’opération de setup. Sur un VPS unique, cela signifie principalement que l’étape de setup doit se terminer avant que l’API soit signalée comme saine. C’est pourquoi le fichier compose fournit des health checks et que la commande de démarrage utilise --wait.

Pour quel projet chaque solution est conçue, et où elle atteint ses limites

Keycloak est le serveur d’identité de Red Hat. Il cible les organisations qui utilisent des realms, des groupes, des mappings de rôles et un annuaire d’entreprise existant. C’est l’implémentation des standards la plus complète des trois. Il atteint ses limites sur un VPS de 2 GB qui héberge quatre applications auto-hébergées, dont la moitié ne prend pas en charge OIDC. Vous consacrez 1250 MB au serveur Keycloak, avant même sa base de données. Vous devez assimiler un modèle de realm conçu pour une entreprise. Vous installez ensuite quand même oauth2-proxy pour les applications qui vous intéressaient réellement.

authentik cible les adeptes de l’auto-hébergement, comme le montre sa liste de fonctionnalités. Il fournit le forward auth et un provider LDAP. Il permet de construire les login flows dans un éditeur visuel. Il atteint ses limites lorsque vous voulez un support éditeur sans budget enterprise, ou un cycle de versions qui ne change pas toutes les quelques semaines. Le support est uniquement disponible avec un abonnement payant : le support par ticket est inclus dans les abonnements Enterprise à plus de $1k, et le support dédié avec des SLA est proposé avec Enterprise Plus, à partir de $20k par an. Le versioning par calendrier, sans possibilité de downgrade ni de saut de version, demande un véritable travail opérationnel. L’éditeur de flows représente aussi tout un modèle à apprendre lorsque votre problème réel se limite à un client OIDC.

Zitadel est conçu pour les développeurs qui intègrent l’authentification à un produit qu’ils publient, avec une API robuste et le multi-tenancy comme fonctionnalités de premier niveau. Il atteint ses limites précisément dans ce cas. Quatre conteneurs, l’absence de forward auth et une base de données dimensionnée à 4 GB par core ne conviennent pas à un VPS qui héberge un password manager et un wiki.

Ce que j’exécuterais sur un VPS, et comment

Pour un VPS qui héberge trois ou quatre applications auto-hébergées, utilisez authentik. Les trois solutions affichent un écran de connexion. Le critère déterminant est que certaines de vos applications ne parleront jamais OIDC, et qu’authentik répond à ce besoin avec la forward auth intégrée, sans ajouter un autre composant à côté.

Allouez-lui 4 GB si possible, et seulement 2 GB si les applications qui tournent à côté sont peu gourmandes. N’exposez pas le port 9000 à Internet et terminez TLS sur un reverse proxy placé devant. Effectuez des dumps PostgreSQL chaque nuit et stockez-les sur une autre machine, car un identity provider sans sauvegarde constitue un single point of failure pour toutes les applications placées derrière lui. Exécutez la stack avec un compte dédié non privilégié plutôt qu’avec root : configurer des utilisateurs avec le principe du moindre privilège sur un VPS décrit le compte et la propriété des fichiers nécessaires.

Choisissez plutôt Keycloak lorsque toutes les applications que vous protégez parlent déjà OIDC ou SAML, ou lorsque vous avez besoin du modèle de rôles détaillé fourni par les realms Keycloak. Choisissez Zitadel lorsque vous développez une application à laquelle d’autres personnes doivent pouvoir s’inscrire et que vous voulez utiliser son API et son modèle de tenants. Aucun de ces deux outils ne correspond au cas de trois applications sur une seule machine traité dans cet article.

Les modes de panne que vous rencontrerez en premier

Keycloak n’a plus aucune donnée après un redémarrage. Vous l’avez démarré avec start-dev, qui utilise une base de données locale de développement. Dans un conteneur sans volume, la suppression du conteneur supprime le realm. Passez à start avec KC_DB=postgres configuré pour utiliser une vraie base de données.

Le conteneur worker d’authentik disparaît sur une petite machine. Le worker et le serveur utilisent la même image et exécutent tous deux des processus Python. PostgreSQL doit également utiliser une partie des ressources d’un hôte de 2 GB. Exécutez docker compose ps pour confirmer quel service s’est arrêté, puis consultez dmesg pour vérifier si le processus a été tué par manque de mémoire, avant de chercher un bug dans l’application.

La Console de Zitadel ne fonctionne pas derrière votre proxy. L’API Zitadel utilise gRPC, qui nécessite HTTP/2 jusqu’à l’upstream. La page des prérequis demande un reverse proxy prenant en charge les connexions HTTP/2 vers l’upstream. Elle cite les versions testées de Traefik v3.x, NGINX v1.x, Caddy v2.x et Apache httpd 2.4.x. Un proxy qui rétrograde la connexion vers l’upstream en HTTP/1.1 vous donne une page de connexion qui se charge, mais une Console qui échoue.

Chaque application vous renvoie vers l’écran de connexion. L’URL publique du serveur SSO et l’URL configurée dans l’application doivent correspondre exactement, y compris le schéma et le port. Keycloak appelle ce paramètre hostname, tandis que Zitadel l’appelle external domain. Lorsqu’elles diffèrent, l’application redirige vers une page de connexion que le serveur ne reconnaît pas comme la sienne, et le navigateur bascule entre les deux.

FAQ

Lequel des trois convient à un VPS de 2 Go ?

authentik et Keycloak. La configuration minimale requise pour authentik est un hôte avec au moins 2 cœurs CPU et 2 Go de RAM. Le guide de dimensionnement de Keycloak indique une consommation de base de 1250 Mo pour le serveur, sans compter la base de données. Ces deux solutions sont à l'étroit sur 2 Go une fois les applications protégées ajoutées ; considérez 4 Go comme un seuil confortable. Le guide Docker Compose de Zitadel mentionne également 2 Go pour une installation en homelab ou en semi-production, mais ses recommandations de production préconisent 4 cœurs CPU pour le hachage des mots de passe et 4 Go de RAM par cœur de base de données. Attendez-vous donc à ce que 2 Go deviennent insuffisants dès l'arrivée de trafic de connexion réel.

Keycloak ou Zitadel peuvent-ils protéger une application qui ne gère pas ses propres connexions ?

Pas seuls. Aucun des deux ne propose de composant de type "forward auth". L'ancien proxy compagnon de Keycloak, Louketo Proxy, a atteint sa fin de vie en novembre 2020 et son dépôt GitHub est archivé depuis décembre 2020 ; il ne faut donc pas baser une architecture dessus. Vous devez placer oauth2-proxy ou un composant similaire entre votre reverse proxy et l'application, puis le pointer vers un client OIDC sur le serveur SSO. authentik gère cela nativement avec son fournisseur de proxy en mode "Forward auth (single application)" ou "Forward auth (domain level)".

Lequel peut agir comme serveur LDAP pour une application qui ne communique qu'en LDAP ?

authentik. Son fournisseur LDAP s'exécute sur un outpost et permet de rechercher les utilisateurs et groupes d'authentik via LDAP, avec LDAPS disponible sur le port 636. Sa documentation ne couvre que le bind et la recherche ; considérez donc cette fonction comme étant en lecture seule. Keycloak et Zitadel fonctionnent dans l'autre sens : ils lisent tous deux depuis un annuaire LDAP existant comme source d'utilisateurs, et aucun des deux ne répond à une requête de bind LDAP provenant d'une application.

Puis-je sauter des versions lors de la mise à jour d'authentik ?

Non. La documentation précise que les mises à jour doivent suivre la séquence des versions majeures et qu'il ne faut pas passer directement d'une ancienne version majeure à la plus récente. Passez d'abord à la dernière version de correctif (patch) de chaque version, puis montez d'une version à la fois. Sauvegardez PostgreSQL avant chaque étape, car authentik ne prend pas en charge les retours en arrière (downgrade) et les migrations ne s'exécutent que dans un sens.