n8n credentials : gérer les secrets et tokens en sécurité

Si tu utilises n8n en production, tu manipules des dizaines de secrets : tokens OAuth, clés API Stripe, identifiants base de données, JWT, certificats. Et chacun de ces secrets, s’il leak, c’est potentiellement un compte vidé, une base de données exfiltrée, ou un service tiers qui te facture 50 000 € de surconsommation API. La gestion des credentials n8n n’est pas un détail — c’est le cœur de ta posture sécurité.

Je vois trop d’instances n8n self-hosted en clair, sans chiffrement de la base, avec des admins qui partagent leur mot de passe, sans rotation des tokens depuis 18 mois. Et je vois aussi des équipes qui font ça parfaitement. La différence ne tient pas à la taille de l’entreprise — elle tient à la connaissance des bonnes pratiques. Voici tout ce que tu dois savoir, condensé en un guide actionnable.

Comprendre comment n8n stocke les credentials

n8n stocke les credentials dans sa base de données (SQLite par défaut, PostgreSQL en production). Mais pas en clair : chaque credential est chiffré avec une clé symétrique appelée N8N_ENCRYPTION_KEY. Si tu ne définis pas cette variable, n8n en génère une au premier démarrage et la stocke dans ~/.n8n/config.

Ça soulève un problème majeur : si quelqu’un a accès à ta base ET à ~/.n8n/config, il peut tout déchiffrer. Pire, si tu perds ce fichier (panne disque, migration mal gérée), tu perds tous tes credentials. Et tu ne peux pas les “récupérer” en lisant la DB — les valeurs y sont incompréhensibles sans la clé.

Les trois règles de base

1. Définis N8N_ENCRYPTION_KEY explicitement dans tes variables d’environnement avant le premier démarrage. Une chaîne aléatoire de 32 caractères minimum. Génère-la avec openssl rand -base64 32.
2. Backup la clé séparément de la base de données. Mets-la dans un password manager type 1Password ou Bitwarden, ou dans un secret manager cloud (AWS Secrets Manager, Vault).
3. Ne mets jamais cette clé dans Git, dans un fichier .env versionné, ou dans ton image Docker. Elle se passe à l’exécution uniquement (via docker run -e, Kubernetes Secret, etc.).

Si tu n’as fait aucune de ces trois choses sur ton instance actuelle, arrête de lire et corrige maintenant. Voici comment :

# 1. Générer une clé forte
openssl rand -base64 32
# => sortie du genre: xK9p2qR8mN3vL5jH7yU4tZ1wB6aF8cE0...

# 2. Stocker la clé dans ton secret manager / password manager

# 3. Redémarrer n8n avec
docker run -d --name n8n \
  -e N8N_ENCRYPTION_KEY="xK9p2qR8mN3vL5jH7yU4tZ1wB6aF8cE0..." \
  -e DB_TYPE=postgresdb \
  ... \
  n8nio/n8n

Important : si tu changes la clé alors que tu as déjà des credentials enregistrés, n8n ne pourra plus les déchiffrer. Il faut soit recréer tous tes credentials, soit faire une migration (n8n a une commande n8n encryption-key-update mais elle ne marche que dans certains cas, vérifie la doc de ta version).

Variables d’environnement vs credentials n8n : choisir le bon mécanisme

Tu as deux endroits où stocker un secret dans un workflow :

1. Credentials n8n — l’interface visuelle, gérée dans Settings > Credentials
2. Variables d’environnement accessibles via $env.VARIABLE_NAME dans les nœuds Code/Function ou les expressions

Quand utiliser quoi ?

Cas d’usage	Recommandation
Token API d’un service tiers utilisé par un nœud natif (Slack, HubSpot…)	Credentials n8n
Token OAuth qui nécessite un refresh automatique	Credentials n8n (n8n gère le refresh)
Secret utilisé uniquement dans du code custom (HMAC, signature)	Variable d’environnement
Configuration multi-environnement (dev/staging/prod)	Variable d’environnement
Clé partagée entre plusieurs workflows	Variable d’environnement

La règle simple : si le secret est consommé par un nœud natif, utilise le système de credentials. Si c’est dans ton code, passe par $env. Ça t’évite d’exposer des secrets dans des expressions ou des nœuds Set qui apparaissent dans les logs.

OAuth et refresh tokens : ce que n8n fait pour toi

Pour les services en OAuth (Google, Microsoft, HubSpot, Salesforce…), n8n gère automatiquement le refresh du token. Tu fais l’auth une fois via l’interface, n8n stocke l’access token et le refresh token, et avant chaque appel, si l’access token est expiré, il en demande un nouveau au provider OAuth.

Mais il y a des pièges :

• Le refresh token peut expirer aussi, après 90 jours d’inactivité chez Google par exemple. Si ton workflow ne tourne pas pendant 3 mois, l’auth est cassée et il faut refaire le flow OAuth manuellement.
• Si tu changes le mot de passe du compte Google, tous les refresh tokens sont invalidés. Tu dois reauthentifier.
• Les permissions (scopes) sont gravées à la création du credential. Si tu veux ajouter un scope, tu dois refaire l’OAuth.

Pour les workflows critiques en production, prévois un monitoring d’expiration des credentials. Tu peux le faire avec n8n lui-même : un workflow planifié qui essaie un appel test sur chaque credential important et t’alerte si ça échoue.

External Secrets : la solution propre pour la prod

n8n Cloud Pro et la version Enterprise self-hosted supportent les External Secrets. Plutôt que de stocker les credentials dans la base n8n, on les référence depuis un secret manager externe : AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager.

Avantages :

• Rotation automatique — tu changes le secret dans Vault, n8n le récupère au prochain appel, sans toucher au workflow
• Audit centralisé — qui a lu quel secret, quand
• Separation of duty — l’équipe DevOps gère les secrets, l’équipe automation crée les workflows, sans chevauchement
• Conformité — exigé par certains référentiels (HDS, ISO 27001, SOC 2)

Mise en place avec Vault (résumé) :

# Variables d'env n8n
N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL: 300
EXTERNAL_SECRETS_VAULT_ADDR: https://vault.workflowpro.fr
EXTERNAL_SECRETS_VAULT_TOKEN: hvs.xxx
EXTERNAL_SECRETS_VAULT_NAMESPACE: n8n-prod

Ensuite dans n8n, dans Settings > External Secrets, tu actives Vault, tu pointes un path KV2, et tes secrets deviennent accessibles via la syntaxe {{ $secrets.vault.stripeApiKey }} dans tes credentials et expressions. Plus jamais une valeur en clair quelque part.

Si tu es en version Community sans External Secrets, tu peux émuler ça à pauvre avec un workflow qui lit Vault via HTTP, met à jour les credentials n8n via l’API REST, et tourne toutes les 5 minutes. C’est sale mais ça marche.

Multi-utilisateurs : isoler les credentials par projet

Depuis n8n 1.0, l’option Projects (Enterprise/Cloud) permet de regrouper workflows, credentials et users dans des espaces isolés. C’est essentiel quand :

• Tu as plusieurs clients sur la même instance et tu veux qu’ils ne voient pas leurs credentials respectifs
• Tu as des environnements de dev/staging/prod sur la même instance et tu veux éviter qu’un workflow de dev utilise par erreur une clé Stripe live
• Tu as des équipes (marketing, finance, RH) qui ont leurs propres secrets et qui ne doivent pas avoir accès à ceux des autres

Sans Projects, tout user avec le rôle Member voit tous les credentials. C’est une exposition surface énorme.

À défaut de Projects, sépare les environnements dans deux instances n8n distinctes. C’est un peu plus de friction opérationnelle mais beaucoup plus sain. Notre guide self-hosting n8n explique comment monter une instance dédiée pour 5 €/mois.

Audit et rotation : la discipline qui change tout

Un secret qui traîne 18 mois sans rotation est un secret compromis (à terme). Voici la routine que je recommande à mes clients :

Inventaire mensuel

Liste tous les credentials de chaque instance n8n. Pour chacun :

• Date de création / dernière rotation
• Quels workflows l’utilisent
• Qui l’a créé / modifié
• Scope d’accès (full access ? read-only ? limité à un sous-domaine ?)

Tu peux automatiser cet inventaire avec l’API REST n8n : endpoint /credentials retourne la liste, et tu peux croiser avec /workflows pour voir où ils sont référencés.

Rotation trimestrielle

Pour les secrets sensibles (Stripe live, AWS, base de production), rotation tous les 90 jours. Pour les moins critiques, semestrielle. Le process :

1. Générer un nouveau secret côté provider
2. Le mettre dans le secret manager / dans n8n
3. Lancer un workflow test qui utilise le nouveau credential
4. Si OK, révoquer l’ancien secret côté provider

Note : pour les services qui ne supportent qu’un seul token actif (rare mais ça existe), prévois une fenêtre de maintenance courte.

Révocation immédiate sur départ

Si un employé qui avait accès à n8n part (ou se fait virer), change tous les secrets auxquels il avait accès dans les heures qui suivent. Pas demain, pas la semaine prochaine. Maintenant. Beaucoup d’attaques internes commencent par un employé qui réutilise un token n8n une fois parti.

Erreurs classiques que je vois en consulting

Voici les top patterns dangereux que je repère en audit (et qui devraient déclencher une alerte rouge chez toi) :

• Une clé API Stripe live utilisée à la fois en dev et en prod — sépare TOUJOURS
• Tous les workflows tournent avec un seul user admin “n8n” — pas de traçabilité
• N8N_ENCRYPTION_KEY égale à la valeur par défaut auto-générée sans backup
• Variables d’env chargées depuis un fichier .env versionné dans Git (vérifié dans le .gitignore)
• L’instance n8n exposée publiquement sans 2FA activé sur les comptes
• Pas de monitoring des échecs d’auth — un attaquant peut bruteforcer en silence
• Le webhook url contient le nom du client (ex: /webhook/acme-corp-stripe) — donne des indices à un scanner

Bonnes pratiques résumées

1. N8N_ENCRYPTION_KEY explicite et backupée, jamais en clair dans Git
2. PostgreSQL chiffré au repos (LUKS, encrypted EBS, etc.)
3. HTTPS obligatoire, certificats Let’s Encrypt auto-renouvelés
4. 2FA activé sur tous les comptes n8n
5. External Secrets si Enterprise/Cloud Pro, sinon discipline de rotation manuelle
6. Projects pour isoler les contextes (clients, environnements, équipes)
7. Audit mensuel des credentials, rotation trimestrielle des secrets critiques
8. Webhooks signés HMAC (voir notre guide webhook n8n)
9. Backups chiffrés de la DB + de la clé d’encryption, stockés dans des emplacements différents
10. Logs centralisés (Loki, Datadog) avec alertes sur les échecs d’auth anormaux

Conclusion

La sécurité des credentials n8n n’est pas un sujet glamour, mais c’est ce qui sépare une automatisation pro d’une bombe à retardement. Avec une instance bien configurée, des secrets externalisés, et une discipline de rotation, tu peux gérer 100+ workflows critiques sans craindre la fuite.

Si tu n’es pas sûr de ton niveau de sécurité actuel, on propose un audit complet de ton stack n8n : inventaire des credentials, vérification du chiffrement, recommandations actionnables sous 48 h. Réserve via audit automatisation, je te livre un rapport priorisé avec les correctifs à appliquer en premier.