Authentik vs ZITADEL vs Keycloak : quel SSO auto-hébergé choisir ?

Vous avez huit conteneurs Docker qui tournent sur un VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, une page de statut et une application interne que vous avez écrite vous-même. Chacun a son propre identifiant. Vous copiez-collez des mots de passe depuis votre gestionnaire chaque matin, et vous commencez à vous demander si l'authentification unique vaut son coût opérationnel.

En général, oui. La question est de savoir quel fournisseur d'identité faire tourner.

Keycloak est le choix par défaut le plus connu, mais la meilleure option dépend de votre pile, du nombre d'utilisateurs que vous gérez, et de savoir si vous intégrez des logiciels déjà en place ou si vous construisez l'authentification dans vos propres applications.

Ce comparatif des SSO auto-hébergés examine Authentik, ZITADEL, Keycloak et Authelia à travers les décisions qui comptent une fois déployés : prise en charge des protocoles, gestion des utilisateurs, flux de travail développeur, ressources requises, et ce qui se passe quand votre fournisseur d'identité tombe.

Pourquoi le SSO auto-hébergé compte

Dès que plusieurs applications dépendent des mêmes personnes et des mêmes groupes, les identifiants séparés cessent d'être pratiques. Un fournisseur d'identité auto-hébergé vous donne un seul endroit pour gérer comptes, MFA, appartenance aux groupes et politiques d'accès, au lieu de configurer ces contrôles séparément dans chaque application.

Le compromis est tout aussi important : l'IdP devient une infrastructure dont dépendent les autres applications. Les nouvelles connexions et les renouvellements de jetons peuvent échouer quand il est indisponible, donc sauvegardes, accès de secours, mises à jour et disponibilité comptent plus ici que pour une application auto-hébergée ordinaire.

En bref

Choisissez Authentik si vous voulez la meilleure option par défaut

Pour un homelab, une pile d'outils internes ou une petite équipe qui connecte des applications existantes via OIDC ou SAML, Authentik est le choix par défaut le plus solide. Son flux d'administration est plus abordable que celui de Keycloak, il prend en charge plusieurs méthodes d'intégration, et sa configuration Docker Compose officielle démarre à 2 cœurs CPU et 2 Go de RAM.

Choisissez ZITADEL si vous construisez des applications

Choisissez ZITADEL quand l'authentification fait partie du produit que vous construisez. Son modèle d'organisations, ses API, sa multi-location, OIDC, SAML, les passkeys, la MFA et la prise en charge de fournisseurs d'identité LDAP ont plus de sens pour des équipes SaaS et B2B que pour un homelab classique.

Choisissez Keycloak si vous avez besoin de fonctions d'identité d'entreprise

Choisissez Keycloak quand vous avez besoin d'une fédération LDAP ou Active Directory plus poussée, de plusieurs realms, de politiques d'autorisation fines, ou d'un environnement déjà construit autour de Keycloak. Sa documentation recommande une limite mémoire de 2 Go pour les petits conteneurs Keycloak prêts pour la production ; un VPS tout-en-un qui fait aussi tourner PostgreSQL a besoin de marge supplémentaire.

Autre option : choisissez Authelia si vous avez surtout besoin d'un mur de connexion

Choisissez Authelia quand votre problème principal est de protéger des applications au niveau du reverse proxy plutôt que de faire tourner une plateforme d'identité complète. Il peut aussi servir de fournisseur OpenID Connect, mais l'authentification au reverse proxy reste son centre de gravité.

Que vérifier avant de choisir un outil SSO

Avant de comparer les fonctionnalités, confrontez chaque outil aux applications, protocoles et sources d'identité que vous devez déjà prendre en charge.

Combien d'applications ont besoin du SSO ?

Partez des applications, pas du fournisseur d'identité. Une pile de six applications qui gèrent déjà OIDC ou SAML est un problème différent d'une pile de vieux outils internes qui ignorent tout de ces deux protocoles. Le premier cas pointe vers un IdP complet. Le second peut nécessiter l'authentification au niveau du reverse proxy.

Vos applications prennent-elles en charge OIDC ou SAML ?

OIDC est le choix courant pour les applications web modernes. SAML compte encore dans les logiciels d'entreprise et les intégrations plus anciennes. LDAP peut compter quand l'application attend un annuaire plutôt qu'un flux SSO web. Vérifiez ce que chaque application accepte réellement avant de choisir l'IdP qui se placera au milieu.

Gérez-vous des utilisateurs ou intégrez-vous la connexion dans une application ?

Si l'essentiel de votre travail se fera dans une interface d'administration pendant que vous connectez des applications existantes, Authentik est le point de départ naturel. Si l'authentification fait partie d'un produit que vous construisez et que vous comptez provisionner organisations, utilisateurs et permissions par du code, ZITADEL est bien plus proche de ce flux de travail.

Avez-vous besoin de LDAP, d'Active Directory ou de politiques avancées ?

Authentik, ZITADEL et Keycloak peuvent tous se connecter d'une manière ou d'une autre à des sources d'identité LDAP, donc LDAP seul ne tranche plus la comparaison. Keycloak devient plus intéressant quand la fédération d'annuaire se combine à plusieurs realms, des mappers détaillés, des exigences de synchronisation ou des politiques d'autorisation au niveau des ressources.

Authentik vs ZITADEL vs Keycloak vs Authelia

Les quatre outils se recoupent sur le SSO, mais ils abordent l'identité par des angles différents : intégration d'applications, identité produit, IAM d'entreprise et accès via reverse proxy.

Authentik

Authentik exécute son déploiement de base sous la forme d'un serveur, d'un worker et d'une base de données PostgreSQL. Redis ne fait plus partie de la pile : Authentik a complètement supprimé cette dépendance dans la version 2025.10. La documentation Docker Compose actuelle exige un hôte avec au moins 2 cœurs CPU et 2 Go de RAM.

Le trait distinctif, c'est l'interface d'administration. Le moteur de flux d'Authentik, le provisionnement d'applications et les politiques par groupe sont plus abordables que le modèle de configuration plus large de Keycloak. Si vous avez déjà configuré une application OIDC dans Keycloak puis passé du temps à comprendre pourquoi vos claims de jeton manquaient, la différence se remarque vite.

Il prend en charge SAML, OAuth2/OIDC, LDAP et RADIUS. C'est le bon choix par défaut pour un homelab ou une petite équipe d'ingénierie qui fait tourner une pile d'applications auto-hébergées.

ZITADEL

ZITADEL est écrit principalement en Go, sous licence AGPL-3.0, et se trouve sur la ligne de versions v4.x. Le déploiement comprend une API en Go, une interface de connexion Next.js et PostgreSQL, et les prérequis actuels prennent en charge PostgreSQL 14 à 18. La documentation Docker Compose officielle exige un hôte avec au moins 2 Go de RAM.

Le trait distinctif, c'est l'API. ZITADEL expose une surface d'identité complète via gRPC et REST et repose dès le départ sur un modèle multi-locataire. Si vous construisez un produit SaaS et voulez une couche de connexion programmable, automatisable et multi-locataire par défaut, ZITADEL est plus proche de ce que vous cherchez que les alternatives.

Il prend en charge OIDC, SAML, les passkeys, la MFA, les fournisseurs d'identité LDAP et une interface SCIM v2 actuellement marquée Preview. Son modèle d'organisations et son flux de travail orienté API en font un meilleur choix pour les équipes produit que pour un simple homelab.

Keycloak

Keycloak est une plateforme de gestion des identités et des accès en Java qui tourne sur Quarkus. Sa surface de configuration est plus large que celle des autres options présentées ici, surtout dès que Realms, Clients, Roles, fédération d'utilisateurs et Authorization Services entrent en jeu.

Sa documentation officielle sur les conteneurs recommande une limite mémoire de 2 Go pour les petits déploiements prêts pour la production. Ce chiffre couvre le conteneur Keycloak lui-même ; si PostgreSQL partage le même VPS, donnez plus de marge à l'hôte.

La raison d'accepter cette complexité est concrète. Keycloak peut fédérer des annuaires LDAP et Active Directory, enregistrer les événements utilisateurs et administrateurs, et appliquer une autorisation fine avec des politiques RBAC, ABAC, par utilisateur, par contexte et d'autres types. Si vous avez besoin de ces contrôles, la configuration supplémentaire a un but.

Authelia

Authelia est le plus petit des quatre : licence Apache 2.0, un seul binaire Go, actuellement en v4.39.x. L'architecture diffère des trois autres : Authelia se place devant un reverse proxy (nginx, Traefik, Caddy, HAProxy) et décide si les requêtes ont le droit d'atteindre le backend.

Authelia inclut aussi un fournisseur OpenID Connect. Sa documentation décrit encore l'implémentation OIDC comme une bêta ouverte, mais le fournisseur est certifié OpenID pour les profils Basic OP, Implicit OP, Hybrid OP, Form Post OP et Config OP. Ses fonctionnalités OIDC sont plus limitées que ce qu'offrent Authentik ou Keycloak pour la gestion des identités, ce qui explique pourquoi Authelia reste le plus pertinent quand l'authentification au reverse proxy est la tâche principale.

Nous reviendrons sur Authelia dans une section dédiée. En résumé : le centre de gravité d'Authelia, c'est le filtrage au reverse proxy, pas la gestion complète des identités.

Comparatif des fonctionnalités

Le tableau ci-dessous limite la comparaison aux différences qui touchent au déploiement et à l'administration quotidienne.

Quel outil pour quelle pile ?

Le meilleur choix change selon qui exploite l'IdP et selon la façon dont les applications s'y intègrent.

Meilleure option pour un homelab

Authentik est le choix par défaut pour un homelab où la plupart des applications gèrent déjà OIDC ou SAML. Il vous donne un fournisseur d'identité complet sans vous obliger à adopter le modèle IAM plus large de Keycloak. Si l'essentiel de la pile a besoin d'un écran de connexion au reverse proxy plutôt que d'un SSO natif, Authelia peut être le choix le plus simple.

Meilleure option pour une pile de petite entreprise

Authentik convient à la plupart des petites piles d'applications internes, surtout quand l'objectif est une seule couche d'identité pour des outils comme Grafana, Gitea, Nextcloud et Vaultwarden. Keycloak devient plus attractif quand un annuaire existant, plusieurs realms ou des politiques d'autorisation plus poussées font partie des exigences.

Meilleure option pour les développeurs et les produits SaaS

ZITADEL est le meilleur choix quand l'authentification fait partie du produit que vous construisez. Son modèle d'organisations, sa multi-location, ses API et sa surface d'automatisation ont plus de sens quand utilisateurs et locataires doivent être provisionnés depuis le code de l'application plutôt que principalement via un panneau d'administration.

LIRE

Le meilleur CIAM auto-hébergé pour les créateurs de SaaS B2B

Meilleure option pour les équipes en entreprise ou soumises à de fortes exigences de conformité

Keycloak a du sens quand la liste des exigences comprend une fédération d'annuaire complexe, plusieurs realms, des politiques d'autorisation détaillées et une équipe capable d'exploiter la complexité IAM supplémentaire. Auto-héberger Keycloak ne rend pas un environnement conforme par lui-même ; sauvegardes, disponibilité, journalisation, revues d'accès et contrôle des changements restent à la charge de votre équipe.

Meilleure option pour les applications sans SSO natif

Authelia est le choix le plus évident quand l'authentification doit se faire avant que les requêtes n'atteignent l'application. Il fonctionne particulièrement bien avec des reverse proxies qui protègent de vieux outils internes, des tableaux de bord et des services qui ne gèrent pas eux-mêmes OIDC ou SAML.

La partie difficile de l'auto-hébergement du SSO

Une fois le SSO obligatoire, une erreur de configuration ou une restauration ratée peut toucher plusieurs applications d'un coup.

Installation et configuration

Faire tourner les conteneurs n'est que la première étape. DNS, TLS, URI de redirection, claims de jetons, mappages de groupes, envoi d'e-mails et accès de secours sont les points où un déploiement SSO commence à devenir de l'infrastructure plutôt qu'une application Docker de plus.

Ressources serveur

L'IdP n'est qu'une partie du budget de ressources. PostgreSQL, reverse proxies, workers, hachage des mots de passe, journaux et synchronisation d'annuaire peuvent tous se disputer le CPU et la mémoire quand ils partagent un même VPS.

Gestion de la base de données et des sauvegardes

Authentik, ZITADEL et les déploiements Keycloak de production classiques dépendent d'une base de données. Sauvegardez cette base hors du serveur, documentez la procédure de restauration et testez-la. Une tâche de sauvegarde réussie n'est pas la même chose qu'une procédure de restauration qui fonctionne.

Risques de verrouillage et de restauration

Un mauvais URI de redirection, un secret client expiré, une connexion d'annuaire cassée ou une politique trop stricte peuvent bloquer les administrateurs en même temps que tout le monde. Gardez un chemin de secours qui ne dépend pas du flux d'authentification que vous essayez de réparer.

Maintenir l'IdP disponible

Une panne de l'IdP ne met pas forcément fin immédiatement à toutes les sessions applicatives existantes. Les sessions en cours peuvent continuer jusqu'à l'expiration de leurs propres jetons ou cookies, mais les nouvelles connexions et les renouvellements de jetons peuvent échouer. Testez ce mode de défaillance avant de rendre le SSO obligatoire sur toute la pile.

Quand vous ne devriez pas auto-héberger le SSO

L'auto-hébergement cesse d'être un bon compromis quand votre équipe ne peut pas restaurer et exploiter la couche d'identité avec la fiabilité que vos applications exigent.

Quand l'identité managée est plus sûre

L'identité managée vaut la dépense quand le coût d'exploitation de l'IdP dépasse le contrôle que vous gagnez à l'auto-héberger. Des services comme Auth0, Clerk, WorkOS et Microsoft Entra ID transfèrent au fournisseur une grande partie de la disponibilité de la plateforme, des correctifs et de la maintenance de l'infrastructure.

Vous restez responsable de la configuration des applications, des permissions et du plan de restauration, mais plus du maintien en ligne de la plateforme d'identité elle-même.

Quand votre équipe ne peut pas gérer une interruption

Si personne dans l'équipe ne sait restaurer l'IdP, réparer PostgreSQL, remplacer un secret expiré ou diagnostiquer une connexion de fédération en panne pendant un incident, auto-héberger l'identité est peut-être le mauvais compromis opérationnel.

La panne dépasse une seule application indisponible. Les nouvelles connexions et les renouvellements de jetons de plusieurs applications peuvent échouer en même temps.

Quand les exigences de conformité sont trop élevées

L'identité auto-hébergée peut être utilisée dans des environnements réglementés, mais faire tourner le logiciel vous-même ne produit pas automatiquement les contrôles ou les preuves qu'un auditeur attend. Votre équipe reste responsable de la journalisation, des revues d'accès, des sauvegardes, de la gestion des changements, de la disponibilité, de la réponse aux incidents et de toute la documentation exigée par le cadre applicable.

Le SSO auto-hébergé n'est pas un symbole de statut. Si votre équipe ne peut pas exploiter la couche d'identité en toute sécurité, payer pour de l'identité managée peut être la meilleure décision d'ingénierie.

Là où Cloudzy aide

Cloudzy change la couche de déploiement ; il ne supprime pas le travail de configuration de l'identité ni d'exploitation décrit plus haut.

Le problème du déploiement SSO manuel

Un déploiement SSO manuel consiste à préparer le serveur, installer l'application et la base de données, configurer le reverse proxy, régler DNS et TLS, et seulement ensuite commencer la configuration de l'identité elle-même. Rien de tout cela ne remplace le travail sur OIDC, SAML, l'annuaire ou les politiques qui vient après.

Déploiement SSO en un clic sur Cloudzy

Cloudzy propose des déploiements en un clic pour Authentik et Keycloak. L'application Authentik en un clic est disponible sur la marketplace Cloudzy. L'application Keycloak en un clic est elle aussi disponible sur la marketplace Cloudzy. ZITADEL n'est pas dans la marketplace aujourd'hui ; déployez-le donc avec sa configuration Docker Compose sur un VPS standard. L'installation en un clic fait tourner l'application de base, tandis que la configuration de l'identité, le DNS, les sauvegardes, les mises à jour, les politiques et les tests de restauration restent sous votre contrôle.

Quand utiliser un VPS séparé pour votre IdP

Cohéberger l'IdP avec vos applications est raisonnable pour un homelab où une interruption est acceptable. Pour une pile critique pour l'activité, séparer le fournisseur d'identité supprime un domaine de défaillance partagé évident : redémarrer, saturer ou compromettre le serveur d'applications ne signifie plus faire tomber la couche d'identité avec lui.

Un VPS séparé n'est pas synonyme de haute disponibilité, mais il donne à l'IdP son propre budget de ressources, son propre calendrier de maintenance et sa propre frontière de restauration.

Recommandations de dimensionnement du VPS

Dimensionnez toute la pile, pas seulement le processus IdP, surtout quand PostgreSQL et un reverse proxy partagent le même VPS.

Prérequis VPS pour Authentik

La documentation Docker Compose officielle d'Authentik exige un hôte avec au moins 2 cœurs CPU et 2 Go de RAM. C'est le bon point de départ pour un petit déploiement. Donnez plus de marge au serveur quand PostgreSQL, des outposts supplémentaires, la synchronisation d'annuaire ou un trafic de connexion plus lourd partagent le même hôte.

Prérequis VPS pour ZITADEL

Le déploiement Docker Compose officiel de ZITADEL exige au moins 2 Go de RAM pour l'hôte. Dimensionnez un VPS tout-en-un pour ZITADEL, son interface de connexion, PostgreSQL et le reverse proxy ensemble, plutôt que de considérer le service Go isolément.

Prérequis VPS pour Keycloak

La documentation sur les conteneurs de Keycloak recommande une limite mémoire de 2 Go pour les petits déploiements Keycloak prêts pour la production. Ce chiffre s'applique au conteneur Keycloak lui-même, pas à un VPS entier qui fait aussi tourner PostgreSQL.

Si Keycloak et PostgreSQL partagent un même VPS, 4 Go de RAM système sont un point de départ raisonnable. Considérez cela comme une recommandation pratique pour l'hôte plutôt que comme le minimum officiel de Keycloak.

Prérequis VPS pour Authelia

Authelia ne publie pas de minimum serveur directement comparable de 1 Go ou 2 Go. Dimensionnez l'hôte pour Authelia avec le reverse proxy, le backend de stockage, l'annuaire d'utilisateurs et tout autre service partageant la machine.

Authelia a généralement une empreinte de déploiement plus réduite qu'un IdP complet accompagné de PostgreSQL, mais les besoins réels en VPS dépendent du reste de la pile.

Exemple de configuration : Authentik avec Vaultwarden

Vaultwarden a ajouté la prise en charge native du SSO OpenID Connect dans la version 1.35.0, en décembre 2025. Authentik est un exemple utile parce que l'intégration expose les briques OIDC que vous rencontrerez aussi avec d'autres applications : URI de redirection, identifiants client, scopes, URL d'émetteur et accès de secours.

Configuration de base d'Authentik

Dans Authentik :

1. Créez un mappage de scope e-mail personnalisé pour Vaultwarden. Vaultwarden exige que le scope email renvoie soit email_verified: true, soit aucune valeur email_verified du tout, alors que le scope e-mail par défaut d'Authentik renvoie actuellement false.
2. Créez une paire application et fournisseur OAuth2/OpenID Connect.
3. Ajoutez https://vault.example.com/identity/connect/oidc-signin comme URI de redirection stricte de type Authorization.
4. Sélectionnez n'importe quelle clé de signature disponible.
5. Notez le Client ID, le Client Secret et le slug de l'application.
6. Réglez la durée de validité du jeton d'accès à plus de cinq minutes.
7. Ajoutez le mappage offline_access d'Authentik aux scopes sélectionnés.
8. Remplacez le mappage e-mail par défaut par le mappage e-mail vérifié personnalisé de l'étape 1.

Configuration OIDC de base de Vaultwarden

Utilisez :

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

Remplacez les domaines d'exemple, le slug de l'application, l'ID client et le secret client par les valeurs de votre propre déploiement, puis redémarrez Vaultwarden.

LIRE

Auto-héberge le gestionnaire de mots de passe Bitwarden : guide complet

Que tester avant d'imposer le SSO

Laissez SSO_ONLY à false pendant que vous testez la connexion, la déconnexion, le renouvellement des jetons, la correspondance des comptes et la restauration. Testez aussi ce qui se passe quand Authentik est temporairement indisponible.

Une fois que le SSO et la restauration fonctionnent comme prévu, vous pouvez décider si exiger le SSO pour chaque connexion a du sens pour votre déploiement.

Les mêmes concepts OIDC s'appliquent à d'autres applications auto-hébergées, mais les URI de redirection, scopes, claims et licences diffèrent. Consultez la documentation SSO de chaque application au lieu de copier telle quelle la configuration Vaultwarden.

Quand Authelia vaut mieux qu'un IdP complet

Authelia devient plus attractif quand l'application n'a pas du tout besoin de comprendre le fournisseur d'identité.

Authentification au reverse proxy

Authelia est avant tout conçu pour protéger les applications au niveau du reverse proxy. Vous définissez des règles de contrôle d'accès, et Authelia décide si une requête doit atteindre le backend avant que l'application elle-même ne gère l'authentification.

Protéger des applications sans OIDC

C'est utile pour les vieux outils internes, les tableaux de bord et les services qui ne gèrent pas OIDC ou SAML. Au lieu de modifier chaque application, vous pouvez placer l'authentification devant elle, au reverse proxy.

Authelia peut aussi servir de fournisseur OIDC, mais l'authentification au reverse proxy reste sa principale force.

Utiliser Authelia avec Authentik

Vous pouvez utiliser Authentik pour les applications qui gèrent OIDC ou SAML et Authelia pour celles qui ont besoin d'une authentification au reverse proxy.

Vous n'avez pas forcément besoin des deux. Authentik prend aussi en charge la protection d'applications par proxy, donc utiliser Authelia à ses côtés n'a de sens que si le flux reverse proxy d'Authelia résout plus proprement une partie précise de votre pile.

Foire aux questions

Authentik est-il meilleur que Keycloak ?

Pour la plupart des homelabs et des petites piles d'applications auto-hébergées, Authentik est plus abordable. Son flux d'administration se concentre sur les applications, les fournisseurs, les groupes et les politiques sans exposer autant de complexité IAM d'un coup.

Keycloak a plus de sens quand vous avez précisément besoin de sa fédération plus poussée, de son modèle de realms ou de ses Authorization Services. Authentik est le meilleur choix par défaut pour un SSO auto-hébergé plus simple ; Keycloak convient aux environnements qui ont besoin de ces contrôles supplémentaires.

ZITADEL est-il meilleur que Keycloak ?

ZITADEL convient mieux quand vous construisez un produit et voulez une identité pilotée par API, des organisations et de la multi-location. Keycloak convient mieux quand vous avez besoin de son modèle d'autorisation plus profond, de ses contrôles de fédération étendus ou d'un environnement déjà construit autour de Keycloak.

Quelle est la différence entre Authentik et Authelia ?

Authentik est un fournisseur d'identité complet construit autour des utilisateurs, groupes, applications, fournisseurs, flux et politiques. Les applications peuvent s'y intégrer directement via des protocoles comme OIDC et SAML.

Authelia est centré sur l'authentification et le contrôle d'accès au reverse proxy. Il inclut aussi un fournisseur OIDC, mais la protection au reverse proxy reste son cas d'usage principal.

Choisissez Authentik quand les applications s'intègrent directement à un IdP. Choisissez Authelia quand l'authentification doit surtout avoir lieu avant que le trafic n'atteigne l'application.

Puis-je faire tourner Authentik sur un VPS de 1 Go ?

Pas comme point de départ pris en charge. La documentation Docker Compose actuelle d'Authentik exige au moins 2 cœurs CPU et 2 Go de RAM. Le déploiement de base actuel utilise le serveur Authentik, le worker et PostgreSQL ; Redis a été complètement retiré dans Authentik 2025.10.

Prenez 2 Go comme point de départ minimal pour une petite installation et ajoutez de la marge quand d'autres services partagent la machine.

Vaultwarden prend-il en charge le SSO OIDC ?

Oui. Vaultwarden a ajouté la prise en charge du SSO OpenID Connect dans la version 1.35.0, en décembre 2025. Il nécessite un fournisseur OIDC externe comme Authentik, Keycloak ou ZITADEL.

La configuration exacte dépend du fournisseur. Avec les versions actuelles d'Authentik, l'intégration documentée comprend un mappage de scope e-mail vérifié personnalisé, offline_access, les identifiants client et l'URL d'émetteur de l'application Authentik.

Dois-je faire tourner mon IdP sur le même VPS que mes applications ?

Pour un homelab où une interruption est acceptable, le cohébergement peut être raisonnable. Pour des applications critiques pour l'activité, un VPS séparé donne au fournisseur d'identité son propre budget de ressources et retire le serveur d'applications du domaine de défaillance partagé.

Cela ne crée pas de haute disponibilité en soi, mais un redémarrage du serveur d'applications, un problème de ressources ou une compromission ne fait plus automatiquement tomber l'IdP avec lui.

Quel SSO auto-hébergé est le plus facile à utiliser ?

Authentik est le point de départ le plus facile pour la plupart des gens qui connectent des applications auto-hébergées existantes. Son interface d'administration rend applications, fournisseurs, groupes et politiques plus abordables que le modèle plus large de realms et d'autorisation de Keycloak.

Authelia peut être plus simple quand vous n'avez besoin que de l'authentification au reverse proxy. ZITADEL a plus de sens quand la personne qui configure l'identité est un développeur qui travaille principalement via des API.