SSO gratuit devant n8n self-hosted : Authelia sans licence Enterprise

La Community Edition de n8n n'a pas de SSO, pas de SAML, pas d'annuaire LDAP intégré — ces briques sont réservées aux plans payants, comme on le détaille dans notre guide n8n gratuit : ce que la licence permet vraiment. Concrètement, une instance self-hosted repose sur un compte email et mot de passe géré par n8n lui-même, sans second facteur natif ni fournisseur d'identité central. Pour une instance perso ou une toute petite équipe, ce n'est pas gênant. Pour une équipe qui grandit, ou une instance exposée sur Internet avec des credentials sensibles à l'intérieur, ça l'est. La solution ne consiste pas à attendre le budget Enterprise : elle consiste à poser une porte d'authentification centralisée devant n8n, au niveau du reverse proxy, avec un outil open source comme Authelia.

Ce que la licence Community ne couvre pas — et pourquoi ça compte

Sans SSO, chaque membre de l'équipe a son propre mot de passe n8n, choisi et retenu comme n'importe quel mot de passe parmi la douzaine que chacun jongle déjà. C'est précisément le terrain qui inquiète en sécurité : une étude de Das, Bonneau, Caesar, Borisov et Wang, présentée au symposium NDSS 2014, a analysé plusieurs centaines de milliers de mots de passe issus de fuites réelles et montré qu'entre 43 % et 51 % des utilisateurs réemploient le même mot de passe, ou une variante prévisible, sur plusieurs sites — au point qu'un algorithme de « guess inter-site » retrouve 30 % des mots de passe transformés en moins de cent tentatives (Das et al., 2014, NDSS Symposium). Une instance n8n exposée avec un simple couple email/mot de passe hérite du même risque que n'importe quel autre compte web du même utilisateur : la faille ne vient pas forcément de n8n, elle vient d'ailleurs et se propage via le mot de passe recyclé.

Le rôle owner/member de n8n (détaillé dans notre guide utilisateurs et permissions n8n self-hosted) reste opérant, mais rien dans la Community Edition ne force une politique de mot de passe robuste, une expiration de session courte ou un second facteur. C'est exactement ce que couvre une couche d'authentification en amont.

Le principe : une porte, pas un module n8n

Authelia est un portail d'authentification open source qui s'intercale entre votre reverse proxy (Nginx, Traefik ou Caddy) et vos applications internes. Le mécanisme s'appelle le forward auth : chaque requête entrante vers n8n.votredomaine.fr est d'abord soumise à Authelia, qui vérifie s'il existe une session valide. Sans session, l'utilisateur est redirigé vers le portail Authelia, saisit son identifiant, son mot de passe et, si vous l'activez, un code TOTP — avant même d'apercevoir l'écran de connexion natif de n8n.

Point important à ne pas survendre : Authelia ne fusionne pas son identité avec celle de n8n. La Community Edition ne sait pas lire un en-tête Remote-User transmis par le proxy pour ouvrir automatiquement une session applicative — cette liaison fine fait partie de ce que le SSO Enterprise apporte en plus. Ce que vous obtenez avec Authelia, c'est un verrou réseau robuste et centralisé en amont : sans lui, l'écran de connexion n8n n'est même pas atteignable. Pour une petite équipe, un compte n8n unique derrière ce verrou suffit souvent ; pour des comptes individuels, chacun garde son compte n8n classique, qu'Authelia protège d'une couche supplémentaire avant de le laisser apparaître.

Déployer Authelia devant n8n avec Docker Compose

Si votre instance tourne déjà en Docker (voir notre guide d'installation n8n avec Docker) et derrière Nginx ou Traefik (voir nos guides Nginx reverse proxy et HTTPS avec Traefik ou Caddy), Authelia s'ajoute comme un service de plus dans le même docker-compose.yml :

services:
  authelia:
    image: authelia/authelia:latest
    volumes:
      - ./authelia:/config
    environment:
      - TZ=Europe/Paris
    restart: unless-stopped

Le fichier configuration.yml monté dans ./authelia définit le fournisseur d'identité local (ou un annuaire LDAP existant si vous en avez déjà un), la politique de mot de passe, et surtout les règles de contrôle d'accès par domaine :

access_control:
  default_policy: deny
  rules:
    - domain: n8n.votredomaine.fr
      policy: two_factor
    - domain: n8n.votredomaine.fr
      resources:
        - "^/webhook.*"
        - "^/webhook-test.*"
        - "^/form.*"
      policy: bypass

La dernière règle est celle qu'on oublie le plus souvent, et elle casse tout silencieusement si elle manque : les chemins /webhook, /webhook-test et /form doivent rester en bypass, sans authentification Authelia, sinon Stripe, GitHub ou tout appelant externe légitime se heurte à une page de connexion HTML au lieu d'atteindre votre workflow. La sécurité de ces routes reste de la responsabilité de n8n lui-même — Header Auth, vérification de signature HMAC — comme détaillé dans notre guide de sécurisation des webhooks n8n.

Côté Nginx, l'intégration passe par une sous-requête interne vers l'endpoint de vérification d'Authelia avant de laisser passer la requête vers n8n :

location /internal/authelia {
    internal;
    proxy_pass http://authelia:9091/api/verify;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
}

location / {
    auth_request /internal/authelia;
    error_page 401 = @errorauth;
    proxy_pass http://n8n:5678;
}

Avec Traefik, le même résultat s'obtient via un middleware forward-auth déclaré dans les labels du conteneur n8n plutôt qu'un bloc location dédié — la logique de vérification reste identique, seule la syntaxe change.

Activer le second facteur (TOTP)

Une fois le portail en place, activer le TOTP (Google Authenticator, Aegis, ou tout gestionnaire compatible) se fait en quelques lignes dans configuration.yml, sous identity_validation et le fournisseur de notifications (SMTP suffit pour l'envoi des liens de première configuration). C'est le gain le plus direct de la manœuvre : même un mot de passe deviné ou réemployé, comme documenté dans l'étude citée plus haut, ne suffit plus à accéder à l'instance sans le second facteur détenu physiquement par l'utilisateur légitime.

Ce que ça ne remplace pas

Cette approche ferme la porte d'entrée, mais elle ne recrée pas tout ce que propose le SSO Enterprise de n8n : pas de provisioning automatique de comptes n8n distincts par utilisateur SSO, pas de RBAC fin par ressource au-delà du duo owner/member natif, pas d'intégration avec le versionnement Git ou les environnements séparés. Si votre organisation a besoin de ce niveau de gouvernance — traçabilité fine de qui a modifié quel workflow, rôles par projet — ces fonctionnalités restent des arguments légitimes en faveur d'un plan payant, à peser dans notre comparatif n8n self-hosted ou cloud. Authelia répond à un besoin plus ciblé et immédiat : empêcher que n8n soit accessible à quiconque devine ou vole un unique mot de passe.

Cas concret

Pour une petite structure — l'équipe de cinq à dix personnes typique qui exploite les workflows du Pack Conformité & Audit (149 €) sur sa propre instance self-hosted — la configuration la plus simple reste un compte n8n unique (owner) partagé, avec les credentials des différents outils (Supabase, OpenAI) déjà cloisonnés par workflow. Authelia protège l'accès à cet unique compte avec un identifiant par personne, un mot de passe individuel côté portail et un TOTP obligatoire : chaque connexion est individuellement authentifiée et journalisée dans les logs Authelia, même si tout le monde retombe ensuite sur le même compte n8n. C'est un compromis pragmatique, très inférieur en finesse à un vrai RBAC par utilisateur, mais infiniment supérieur à un webhook n8n protégé par le seul mot de passe par défaut resté inchangé depuis l'installation.

En résumé

n8n Community n'offre pas de SSO natif, et ce n'est pas près de changer sans licence Enterprise. Un portail d'authentification comme Authelia, posé devant l'instance au niveau du reverse proxy, ne remplace pas cette fonctionnalité à l'identique — mais il ferme le vrai trou de sécurité : un accès protégé par un seul mot de passe, sans second facteur, potentiellement réemployé ailleurs. Quelques dizaines de lignes de configuration Docker et Nginx (ou Traefik) suffisent à poser cette couche, à condition de ne pas oublier d'exclure vos routes de webhook du filtre.