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 chaque solution a-t-elle réellement besoin ?

Commencez par le seuil de ressources, car il détermine la présélection avant toute fonctionnalité. Les chiffres ci-dessous sont ceux publiés par chaque projet, relevés en août 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é exécute 3 conteneurs : PostgreSQL, le serveur et le worker.

Keycloak publie le chiffre le plus précis des 3. Son guide de dimensionnement indique que « l’utilisation mémoire de base d’un Pod, caches des données Realm et 10 000 sessions en cache compris, est de 1250 MB de RAM ». Ces 1250 MB couvrent uniquement le processus Java, avant la base de données. La même page explique pourquoi la limite du conteneur est si importante : Keycloak utilise 70 % de la limite mémoire pour le heap et consomme environ 300 MB de mémoire non-heap en plus. Avec une limite de 1 GB, il calcule un heap d’environ 717 MB tout en nécessitant ces 300 MB de mémoire non-heap. La limite est donc déjà consommée avant même que les données de session soient placées dans le cache.

La page compose de Zitadel demande elle aussi 2 GB, soit les mêmes 2048 MB, mais ce chiffre concerne un premier démarrage. Il faut consulter sa page consacrée à la production. Le processus Zitadel lui-même nécessite « 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 nécessite ensuite « 4 cœurs CPU disponibles à cet effet », car un pic de connexions se transforme en forte pointe de consommation CPU. Le compose officiel v4 exécute 4 conteneurs avant tout ajout : Traefik comme proxy, l’API Zitadel, un conteneur Login UI séparé et PostgreSQL. Redis et un collector OpenTelemetry sont associés à 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 et, sur une machine qui héberge aussi des applications, je prévoirais 8 GB.

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

authentik utilise PostgreSQL et deux copies d’une même image : un serveur et un worker. Le serveur répond aux requêtes HTTP et contient 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 vous 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 que ce port soit accessible depuis Internet.

Keycloak utilise un processus et une base de données que vous fournissez. Le quickstart tient dans un conteneur unique.

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.7.1 start-dev

start-dev sert à explorer l’interface. Il utilise une base de données locale de développement et aucune couche TLS (transport layer security). Un conteneur démarré de cette façon, puis supprimé, supprime donc aussi votre realm. En production, utilisez plutôt start, avec un PostgreSQL réel via KC_DB et un nom d’hôte public via KC_HOSTNAME. Le guide de production de Keycloak précise également que toutes les communications avec le serveur et depuis celui-ci doivent utiliser un canal sécurisé. HTTPS est donc obligatoire dans ce mode.

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 l’exécution de stacks de ce type, 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 ?

Tous les trois prennent en charge OpenID Connect (OIDC), la couche de connexion qui s’appuie sur OAuth 2.0 et que les applications modernes utilisent. Tous les trois prennent également en charge SAML 2.0 (security assertion markup language), l’ancien standard encore utilisé par les logiciels d’entreprise. La véritable différence concerne LDAP (lightweight directory access protocol), qui recouvre deux fonctions opposées.

Lire dans LDAP signifie que le serveur SSO vérifie les mots de passe dans un annuaire que vous administrez déjà. Keycloak le fait avec 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 bind auprès de votre serveur SSO comme s’il s’agissait de l’annuaire. Seul authentik le permet. Son fournisseur LDAP rend « tous les utilisateurs et groupes de la base de données d’authentik interrogeables via l’annuaire LDAP » grâce à un outpost LDAP dédié, avec LDAPS disponible sur le port 636. Le service est en lecture seule : les opérations de bind et de recherche fonctionnent, mais pas les écritures. 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 d’une bind.

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 bind. 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 qui n’ont aucun système de connexion ?

Le forward auth est la solution. C’est un cas auquel un serveur auto-hébergé est très souvent confronté. 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 ne sait rien du SSO. Elle reçoit des requêtes que le proxy a déjà vérifiées, généralement avec le nom d’utilisateur dans un en-tête.

Le proxy provider d’authentik couvre ce besoin avec trois modes documentés. Le mode « Proxy » fait passer le trafic vers l’application backend par l’authentik outpost lui-même. Le mode « Forward auth (single application) » conserve le trafic sur votre reverse proxy existant et utilise authentik uniquement pour vérifier l’authentification. Le mode « Forward auth (domain level) » protège toutes les applications d’un même domaine parent avec un seul provider. Le niveau domaine est le plus pratique, mais il comporte une limite documentée : il « ne peut pas appliquer des règles d’autorisation différentes au niveau des applications pour chaque application protégée ». Toutes les applications de ce domaine partagent donc le même ensemble de règles.

Keycloak ne propose rien de tout cela. Son proxy compagnon, Keycloak Gatekeeper, a été renommé Louketo Proxy, puis archivé sur GitHub. Son dernier commit date d’août 2023. Pour protéger une application sans prise en charge d’OIDC, vous devez exécuter un composant séparé devant elle, généralement oauth2-proxy, configuré avec un client Keycloak. Zitadel ne possède pas non plus de mode forward auth intégré. La solution consiste donc également à installer, surveiller et mettre à niveau un composant supplémentaire.

C’est à partir de ce saut supplémentaire que la configuration du reverse proxy cesse d’être simple. Consultez donc la procédure pour placer Traefik devant plusieurs applications Docker Compose avant d’y ajouter un middleware d’authentification.

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

En août 2026, les versions actuelles sont Keycloak 26.7.1, authentik 2026.5.6 et Zitadel v4.16.3. Les trois exécutent des migrations de schéma sur PostgreSQL, ce qui signifie que chaque mise à niveau modifie la base de données. Sauvegardez d’abord la base de données, à chaque fois. Cette seule habitude vaut davantage 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 de correctif de chaque version avant de passer à la suivante, et « authentik ne prend pas en charge les rétrogradations ». Lorsqu’un projet utilisant des versions correspondant à des années civiles accuse un an de retard, une mise à niveau devient une suite 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 souhaitez examiner les changements avant leur application. Avec Keycloak, cette lecture représente le principal coût. Les release notes contiennent des fonctionnalités dépréciées et des changements de comportement qu’il est facile d’ignorer, mais 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 séparer afin que la mise à l’échelle ne répète pas les opérations de setup. Sur un VPS unique, cela signifie principalement que l’étape de setup doit se terminer avant que l’API signale un état healthy. C’est pourquoi le fichier compose fournit des health checks et que la commande de démarrage utilise --wait.

Pour quel type de projet chaque solution est conçue, et où chacune montre ses limites

Keycloak est le serveur d’identité de Red Hat. Il est conçu pour les organisations qui utilisent des realms, des groupes, des associations de rôles et un annuaire d’entreprise existant. C’est l’implémentation des standards la plus complète des trois. Il montre 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 à la JVM, vous devez apprendre un modèle de realms conçu pour une entreprise, puis vous installez quand même oauth2-proxy pour les applications qui vous intéressaient réellement.

authentik est conçu pour l’auto-hébergement, comme le montre sa liste de fonctionnalités. Il fournit le forward auth et un fournisseur LDAP, et permet de construire les flux de connexion dans un éditeur visuel. Il montre ses limites lorsque vous avez besoin d’un contrat de support éditeur ou d’un cycle de versions qui n’évolue pas toutes les quelques semaines. Le versionnage par calendrier, sans possibilité de downgrade ni de sauter des versions, impose un véritable travail d’exploitation. L’éditeur de flux constitue aussi un modèle complet à 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 dans un produit qu’ils distribuent, avec une API solide et la multi-tenancy comme fonctionnalités de premier plan. Il montre précisément ses limites dans ce cas. Quatre conteneurs, l’absence de forward auth et une base de données dimensionnée à 4 GB par cœur ne conviennent pas à un VPS qui héberge un gestionnaire de mots de passe 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 GB ?

authentik et Keycloak. La configuration requise indiquée par authentik est un hôte avec au moins 2 cœurs CPU et 2 GB de RAM. Le guide de dimensionnement de Keycloak indique 1250 MB de mémoire de base pour le serveur, sans la base de données. Ces deux solutions sont à l’étroit avec 2 GB une fois les applications protégées ajoutées. Comptez donc 4 GB comme minimum confortable. Zitadel publie une exigence de 2 GB pour une première exécution, mais ses recommandations de production demandent 4 cœurs CPU pour le hachage des mots de passe et 4 GB de RAM par cœur de base de données. Une instance de 2 GB ne constitue donc pas un déploiement réaliste.

Keycloak ou Zitadel peut-il protéger une application qui ne possède pas son propre système de connexion ?

Pas seul. Aucun des deux ne fournit de composant de forward auth. L’ancien proxy complémentaire de Keycloak, Louketo Proxy, est archivé sur GitHub et son dernier commit date d’août 2023. Il ne faut donc pas baser un nouveau déploiement dessus. Placez oauth2-proxy, ou un composant similaire, entre votre reverse proxy et l’application, puis pointez-le vers un client OIDC sur le serveur SSO. authentik propose cette fonction nativement avec son proxy provider, en mode « Forward auth (single application) » ou « Forward auth (domain level) ».

Lequel peut servir de serveur LDAP pour une application qui utilise uniquement LDAP ?

authentik. Son LDAP provider s’exécute sur un outpost et rend les utilisateurs et les groupes d’authentik accessibles par recherche LDAP, avec LDAPS disponible sur le port 636. Il est en lecture seule : les opérations bind et search fonctionnent, mais pas les écritures. Keycloak et Zitadel fonctionnent dans l’autre sens : tous deux lisent un annuaire LDAP existant comme source d’utilisateurs, et aucun ne répond à une opération LDAP bind effectuée par une application.

Puis-je ignorer des versions lors de la mise à niveau d’authentik ?

Non. La documentation précise que les mises à niveau doivent suivre la séquence des versions majeures. Elle déconseille de passer directement d’une ancienne version majeure à la plus récente. Installez d’abord la dernière version corrective de chaque version, puis progressez d’une version à la suivante. Sauvegardez PostgreSQL avant chaque étape, car authentik ne prend pas en charge les rétrogradations et les migrations s’exécutent uniquement vers l’avant.