Héberger ZITADEL sur un VPS : SSO multi-tenant sans Keycloak

La question revient systématiquement dès qu'une agence ou un développeur SaaS cherche à centraliser l'authentification de plusieurs clients : faut-il rester sur Keycloak, passer à Authentik, ou regarder ZITADEL ?

Keycloak est le standard historique, riche en fonctionnalités et supporté par Red Hat. Il couvre OIDC, SAML, LDAP, Kerberos, WebAuthn et dispose d'une documentation exhaustive. Son problème pour un VPS self-hosted : la JVM. Au repos, Keycloak consomme entre 512 Mo et 1 Go de RAM, et chaque realm est une arborescence de configuration distincte à maintenir. La semaine 38 de 2026 a illustré le risque : six CVEs corrigées en deux releases consécutives, dont deux DoS non authentifiés sur les endpoints SAML et de login.

Authentik (2026.8.2) est le choix naturel pour les équipes qui veulent un IdP complet avec une interface graphique, des flux visuels et du provisionnement SCIM. Il est écrit en Python/Django avec un frontend TypeScript, et sa stack complète demande au moins 1 Go de RAM utilisable. Le multi-tenant existe, mais s'implémente via des tenants séparés ou des groupes — pas via un modèle de données dédié.

ZITADEL (v2.x, Go) est le seul des trois à avoir conçu le multi-tenant comme primitif de première classe. Une installation unique expose des organisations indépendantes — chacune avec ses utilisateurs, ses IdP externes, ses politiques de mot de passe et ses applications. Pour une agence qui héberge dix clients sur un seul VPS, c'est la différence entre dix fichiers de configuration Keycloak et une API qui orchestre tout.

ZITADEL est raisonnable en ressources pour un fournisseur d'identité de cette envergure. La configuration minimale recommandée par l'équipe pour un déploiement de production est 2 vCPU et 4 Go de RAM — dont environ 300 Mo seront utilisés par ZITADEL lui-même, le reste revenant à PostgreSQL et aux autres services de votre stack.

En pratique, sur un VPS dédié avec 4 Go de RAM, ZITADEL + PostgreSQL laissent largement de la place pour un reverse proxy nginx, un service de notification et quelques applications. Pour des tests ou un déploiement de développement, 2 Go suffisent.

Logiciels requis : Docker Engine 24+ et Docker Compose v2. Les ports 80 et 443 doivent être ouverts (nginx terminera le TLS). Un nom de domaine pointé vers l'IP de votre VPS — ZITADEL exige un FQDN même en développement, car les cookies OIDC sont liés au domaine. Si vous n'avez pas encore de certificat TLS, Let's Encrypt avec Certbot ou le plugin nginx suffisent.

Base de données : PostgreSQL 15 ou 16. ZITADEL supporte aussi CockroachDB pour les déploiements hautement disponibles, mais sur un VPS single-node, PostgreSQL est le choix naturel. La base doit être accessible depuis le conteneur ZITADEL — le réseau Docker bridge par défaut convient.

Stockage : ZITADEL ne stocke pas de fichiers sur disque (hors logs) — pas de volume de données dédié au-delà du volume PostgreSQL. Prévoir 10 Go pour la base de données en conditions normales d'utilisation.

Une fois ZITADEL démarré et une application OIDC créée, la configuration côté application est standard — n'importe quelle bibliothèque OIDC (passport.js, next-auth, python-oidc, etc.) fonctionne sans adaptation spécifique à ZITADEL.

Les paramètres OIDC essentiels à fournir à votre application :

ISSUER=https://sso.votre-domaine.com
CLIENT_ID=<client_id_généré>
CLIENT_SECRET=<client_secret_généré>  # seulement pour les apps Web (pas les SPAs)
REDIRECT_URI=https://votre-app.com/callback
SCOPES=openid profile email

Le Discovery Document est disponible à https://sso.votre-domaine.com/.well-known/openid-configuration. Il expose automatiquement tous les endpoints : authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri. La plupart des bibliothèques OIDC modernes peuvent se configurer depuis ce seul URL de découverte.

Exemple avec next-auth (Next.js) :

// pages/api/auth/[...nextauth].js
import NextAuth from 'next-auth'

export default NextAuth({
  providers: [
    {
      id: 'zitadel',
      name: 'ZITADEL',
      type: 'oauth',
      wellKnown: 'https://sso.votre-domaine.com/.well-known/openid-configuration',
      clientId: process.env.ZITADEL_CLIENT_ID,
      clientSecret: process.env.ZITADEL_CLIENT_SECRET,
      authorization: { params: { scope: 'openid profile email' } },
      idToken: true,
      checks: ['pkce', 'state'],
      profile(profile) {
        return { id: profile.sub, name: profile.name, email: profile.email }
      }
    }
  ]
})

Pour une SPA (React, Vue), utilisez le flow PKCE sans secret côté client. ZITADEL gère la rotation des codes PKCE nativement — pas de configuration supplémentaire requise.

Le modèle de données ZITADEL s'articule en trois niveaux qui correspondent exactement aux besoins d'une agence ou d'un SaaS B2B.

L'organisation est le conteneur d'un tenant. Chaque organisation a ses propres utilisateurs, ses propres IdP externes (Google, GitHub, SAML d'entreprise) et ses propres politiques de complexité de mot de passe. Elle peut être administrée par un délégué de l'organisation — votre client — sans que cela lui donne accès aux autres organisations.

Le projet regroupe les applications d'un même produit. Un projet peut contenir une application web, une application mobile et une API — toutes partageant les mêmes rôles et permissions, définis une seule fois au niveau du projet. Les tokens JWT émis par ZITADEL portent les rôles du projet dans le claim urn:zitadel:iam:org:project:roles.

L'application représente un client OIDC, OAuth2 ou SAML spécifique. Elle définit les URLs de redirection, le type de client et les scopes autorisés.

Ce modèle permet à une agence de gérer dix clients sur une seule installation ZITADEL sans aucun risque de contamination entre tenants. Comparez avec Keycloak où chaque realm est une configuration complète à maintenir séparément, ou avec Authentik où le multi-tenant s'implémente via des tenants distincts partageant le même espace de noms.

Utiliser l'API pour automatiser : ZITADEL expose une API gRPC/REST complète. Créer une organisation et ses premières applications depuis un script d'onboarding prend une vingtaine de lignes :

# Créer une organisation via l'API REST
curl -X POST https://sso.votre-domaine.com/v1/orgs \
  -H 'Authorization: Bearer <admin_token>' \
  -H 'Content-Type: application/json' \
  -d '{"name": "client-acme", "domain": "acme.example.com"}'

L'API renvoie l'ID de l'organisation, que vous passez ensuite aux appels de création de projet et d'application.

masterkey must be 32 characters : le ZITADEL_MASTERKEY généré par openssl rand -base64 32 produit une chaîne base64 d'une longueur variable selon le padding. Utilisez head -c 32 pour tronquer à exactement 32 caractères, ou une commande qui génère directement 32 octets aléatoires en hexadécimal : openssl rand -hex 16 (32 caractères hex = 16 octets).

connection refused sur le port 8080 alors que le conteneur tourne : ZITADEL ne répond sur :8080 que lorsque les migrations sont terminées — le start-from-init sur une base vide peut prendre 30 à 90 secondes. Attendez le log server is listening on [::]:8080 avant de tester.

Boucle de redirection HTTP/HTTPS : ZITADEL génère ses redirects OAuth2 en HTTPS dès que ZITADEL_EXTERNALSECURE=true. Si nginx n'envoie pas correctement l'en-tête X-Forwarded-Proto: https, ZITADEL croit être derrière HTTP et génère des redirects cassés. Vérifiez que proxy_set_header X-Forwarded-Proto https est bien dans le bloc location / de nginx.

invalid_client lors du flux OIDC : vérifiez que l'URL de redirection déclarée dans l'application ZITADEL correspond exactement à celle envoyée par votre application — ZITADEL est strict sur la correspondance (pas de trailing slash, pas de paramètre supplémentaire). Activez les logs de débogage avec ZITADEL_LOG_LEVEL=debug pour voir le détail des validations.

PostgreSQL refuse la connexion : le conteneur ZITADEL démarre avant que PostgreSQL soit prêt à accepter des connexions, même avec depends_on: condition: service_healthy. Si cela se produit, relancez simplement ZITADEL : docker compose restart zitadel. En production, utilisez une politique de restart (restart: on-failure:5) pour absorber les délais de démarrage.

Perte des credentials admin initiaux : les credentials ne s'affichent qu'une seule fois au premier démarrage. Si vous les perdez, supprimez la base de données PostgreSQL (docker compose down -v) et relancez start-from-init. Sur un VPS de production, créez immédiatement un second compte admin et notez les credentials dans votre gestionnaire de secrets.

ZITADEL en production sur un VPS est un excellent premier pas. Pour aller plus loin :

- [Déployer ZITADEL sur VPS — guide avancé](/deployer-zitadel-vps) : certificats TLS automatiques avec Let's Encrypt, backup PostgreSQL avec pg_dump vers S3, et mise à jour sans downtime.
- [Authentik vs Authelia : quel SSO self-hosted pour votre VPS ?](/authentik-vs-authelia-sso-self-hosted) : si votre cas d'usage est moins orienté multi-tenant et plus orienté proxy d'authentification, la comparaison des deux alternatives les plus légères.
- [Migrer de Keycloak vers Authelia ou ZITADEL](/keycloak-cves-semaine-38-migrer-authelia-zitadel-vps) : les six CVEs de la semaine 38 analysées, et le chemin de migration concret depuis un realm Keycloak existant.
- [Héberger Authelia sur VPS](/self-host-authelia-vps) : si vous cherchez une passerelle d'authentification ultra-légère (moins de 30 Mo) plutôt qu'un IdP complet, Authelia reste la référence.

Un VPS avec 4 Go de RAM, accès root et IPv4 dédiée couvre confortablement ZITADEL en production avec de la marge pour les applications qu'il protège.