Je configure des workflows pour plusieurs utilisateurs différents. Comment puis-je configurer les identifiants pour chacun d’eux sans avoir besoin d’accéder à leurs comptes personnels, ou peuvent-ils simplement les créer eux-mêmes ?
Bonjour @Bobby_Cheung
Si vous utilisez une version de n8n avec la Gestion des utilisateurs activée (disponible dans n8n Cloud et la plupart des installations auto-hébergées), le processus est simple :
- Inviter des utilisateurs : Vous invitez les utilisateurs à votre instance n8n par email.
- Identifiants privés : Une fois qu’ils se connectent, tout identifiant qu’ils créent est privé par défaut.
- Exécution du workflow : Quand vous créez un workflow pour eux, vous pouvez laisser le champ d’identifiant vide ou le définir avec un espace réservé. Quand l’utilisateur ouvre le workflow, il sélectionne simplement son propre identifiant préconfigré dans le menu déroulant.
Pour les services qui prennent en charge OAuth2 (comme Google, Slack, Microsoft, etc.), l’utilisateur n’a jamais à vous donner son mot de passe :
- Vous configurez l’« Application » (ID client et secret client) dans la console développeur du service.
- L’utilisateur clique sur le bouton « Connecter mon compte » dans n8n.
- Il est redirigé vers la propre page de connexion du service (par exemple, l’écran de connexion de Google), où il autorise n8n.
- n8n reçoit un « jeton » pour agir en son nom, mais vous ne voyez jamais ses véritables identifiants de connexion.
Si vous avez créé un « Compte de service » (un compte générique utilisé par l’entreprise) et que vous souhaitez que plusieurs utilisateurs l’utilisent sans connaître le mot de passe :
- Vous créez l’identifiant sous votre compte administrateur.
- Dans les paramètres d’identifiant, vous pouvez partager cet identifiant spécifique avec d’autres utilisateurs ou des rôles spécifiques.
- Les utilisateurs peuvent ensuite sélectionner cet identifiant partagé dans leurs workflows, mais ils ne peuvent pas voir ni modifier la clé API ou le mot de passe réel.
Cela dépend du type d’identifiant que vous configurez.
Pour les services partagés (un bot Slack, une connexion à une base de données, une API interne, bref tout service qui fonctionne avec un seul compte pour toute l’équipe) : vous pouvez créer l’identifiant vous-même, l’ouvrir et cliquer sur l’onglet Partage. Il y a un menu déroulant pour partager avec des utilisateurs ou des projets spécifiques. Ils pourront l’utiliser dans les workflows, mais ils ne verront pas la clé API ou le secret réels. Cela reste verrouillé en tant que propriétaire.
Pour les comptes OAuth personnels (Gmail, Google Drive, Notion de chacun, etc.) : pas d’alternative. Chaque utilisateur doit s’authentifier avec son propre compte. Vous ne pouvez pas le faire à leur place sans vous connecter en tant qu’eux. La bonne nouvelle, c’est que le processus est le même pour eux que pour vous : Identifiants → Ajouter un identifiant → sélectionner le service → suivre le flux OAuth. Tant qu’ils ont un compte n8n sur votre instance, ils peuvent le faire eux-mêmes.
Concrètement : vous configurez les identifiants des services partagés et les partagez, vos collègues créent les leurs pour tout ce qui est lié à leurs comptes personnels.
Une petite chose à savoir : les utilisateurs avec qui vous partagez les identifiants peuvent les utiliser dans les workflows, mais ne peuvent pas voir ni modifier le secret sous-jacent. Si leur token expire ou s’arrête pour une raison quelconque, soit vous partagez un nouveau, soit ils doivent se réauthentifier eux-mêmes. C’est bon à clarifier dès le départ.
Salut ! Je suis tombé sur ce fil de discussion parce que ma propre discussion sur Credential HUB a été liée sous les sujets connexes.
En lisant ton cas d’usage, je pense que tu pourrais faire face à l’un des problèmes que Credential HUB a été conçu pour résoudre : la gestion centralisée des identifiants, l’accès contrôlé pour les workflows, le cycle de vie et la rotation des identifiants, la surveillance de la santé, et une API cohérente pour les plateformes d’automatisation.
Ce peut ou ne peut pas être la bonne solution pour ta configuration, mais si tu es intéressé, voici un aperçu du projet et ce qu’il vise à résoudre :
J’apprécierais vraiment tout retour ou réflexion de la part de personnes confrontées à des défis similaires.
Luis
Salut @Bobby_Cheung
Oui, ils peuvent créer leur propre — et généralement devraient.
Point clé : vous n’avez jamais besoin de leur mot de passe. Pour les services OAuth (Google, Slack, Microsoft), vous configurez l’app une fois et eux cliquent sur Connecter et autorisent leur propre compte.
1. Invitez-les à votre instance. Ils créent les identifiants et les partagent dans un projet. Vous pouvez les utiliser, mais ne pouvez pas voir ni modifier le secret. Fonctionne sur tous les plans Cloud.
Partager un workflow contourne cela — les éditeurs ont accès à chaque identifiant à l’intérieur.
2. Identifiants d’utilisateur final (Enterprise, aperçu). Un modèle d’identifiants, chaque utilisateur connecte son propre compte. Les exécutions utilisent celui qui les a déclenchées.
OAuth uniquement, et déclencheurs manuel/Chat Hub/MCP uniquement — pas planifiés ni webhook.
3. Instance séparée par client. Ils possèdent le compte et vous invitent. Limite la plus nette, transfert facile. Inconvénient : basculer entre instances.
4. Comptes de service (Google uniquement). Le client partage simplement la feuille ou le dossier spécifique avec l’e-mail du compte de service. Aucun compte personnel impliqué.