Introduction
La plupart des API du monde réel refusent les requêtes non authentifiées. Avant de pouvoir extraire des données de Stripe, publier sur Slack ou interroger un CRM, vous devez prouver votre identité. n8n gère cela via son système d'Credentials — un coffre-fort chiffré qui garde les secrets hors du JSON de votre workflow et permet de réutiliser la même configuration d'auth sur plusieurs nœuds.
Cette leçon couvre les trois modèles que vous rencontrerez dans au moins 80 % des intégrations : les clés API passées en en-tête, les jetons Bearer, et le flux de code d'autorisation OAuth2. À la fin, vous saurez comment configurer chacun dans n8n et comment les raccorder à un nœud HTTP Request lorsqu'aucun nœud intégré n'existe pour votre service cible.
Clés API et en-têtes personnalisés
Le modèle d'auth le plus simple : le service vous délivre une clé statique, et vous l'envoyez à chaque requête, généralement dans un en-tête personnalisé comme X-API-Key ou en paramètre de requête.
Dans n8n, allez dans Credentials > Add Credential > Header Auth. Vous fournissez le nom et la valeur de l'en-tête une seule fois, et n8n l'injecte automatiquement à chaque requête utilisant cet identifiant.
Exemple : Connexion à une API météo qui exige une clé dans l'en-tête.
Dans le nœud HTTP Request, réglez Authentication sur Header Auth, sélectionnez votre identifiant enregistré, puis configurez la requête :
n8n ajoute l'en-tête automatiquement — vous ne codez jamais la clé en dur dans le nœud lui-même. Si l'API attend la clé en paramètre de requête (par ex. ?apikey=...), utilisez le type d'identifiant Query Auth au lieu de Header Auth. Même principe, emplacement différent.
Une erreur fréquente consiste à coller la clé directement dans un nœud Set ou un champ d'URL. Cela intègre le secret dans le JSON du workflow, qui sera exporté, versionné et partagé. Utilisez toujours les Credentials.
Jetons Bearer
De nombreuses API — surtout celles suivant le client credentials OAuth2 ou émettant des JWT à courte durée de vie — attendent un en-tête Authorization exactement sous cette forme :
Dans n8n, il s'agit toujours d'un identifiant Header Auth. Mettez le champ Name sur Authorization et le champ Value sur Bearer suivi d'une espace et de votre jeton :
Si votre jeton expire et doit être renouvelé programmatiquement, ajoutez un nœud HTTP Request précédent qui appelle l'endpoint de jeton, extrayez le access_token de la réponse avec une expression comme {{ $json.access_token }}, et passez-le dans l'en-tête Authorization du nœud suivant. Cela crée un simple motif de renouvellement de jeton en deux nœuds sans code personnalisé.
Flux de code d'autorisation OAuth2
OAuth2 avec le flux de code d'autorisation est plus complexe car il nécessite une redirection via le navigateur — l'utilisateur doit se rendre chez le fournisseur, se connecter et accorder la permission avant que n8n reçoive un access token. n8n automatise la majeure partie de ce processus.
Étape 1 : Créez un identifiant OAuth2 API. Allez dans Credentials > Add Credential > OAuth2 API. Remplissez les champs à partir de l'enregistrement de votre application côté fournisseur :
Étape 2 : Configurez l'URI de redirection. n8n vous affiche son URL de callback (quelque chose comme https://your-n8n-instance.com/rest/oauth2-credential/callback). Copiez-la dans le champ Authorized Redirect URIs de votre application OAuth sur le tableau de bord du fournisseur.
Étape 3 : Cliquez sur Connect my account dans n8n. Une fenêtre popup s'ouvre, vous vous connectez et approuvez, et n8n stocke automatiquement les access token et refresh token полученные. À partir de ce moment, n8n gère aussi silencieusement le renouvellement des jetons — quand l'access token expire, il utilise le refresh token pour en obtenir un nouveau sans aucune action de votre part.
Pour les nœuds intégrés comme Google Sheets, Slack ou HubSpot, n8n pré-remplit l'Authorization URL et l'Access Token URL — il vous suffit du Client ID, du Client Secret et de la liste des scopes depuis la documentation du fournisseur.
Erreurs courantes et comment les corriger
401 Unauthorized signifie presque toujours que l'identifiant est mal configuré ou que le jeton a expiré. Vérifiez que le nom de l'en-tête correspond exactement à ce que spécifie la doc de l'API — certaines API utilisent X-Auth-Token, d'autres utilisent api-key (en minuscules), et la différence est invisible jusqu'à l'exécution.
403 Forbidden signifie que le jeton est valide mais qu'il manque le scope requis. Retournez dans votre application OAuth, ajoutez le scope manquant et réautorisez. n8n ne redemande pas automatiquement de nouveaux scopes.
Si la connexion OAuth2 échoue avec une erreur redirect_uri_mismatch, l'URL de callback dans n8n et celle enregistrée chez le fournisseur ne correspondent pas exactement — vérifiez les slashs finaux ou les différences http vs https.
Ne stockez jamais de secrets dans les expressions de workflow ou les paramètres de nœud. n8n chiffre tout dans le store d'Credentials en utilisant la clé de chiffrement de votre instance. Si vous avez besoin de faire tourner une clé, mettez-la à jour une fois dans l'identifiant, et chaque workflow qui l'utilise prend en compte le changement immédiatement.
Résumé
Utilisez Header Auth pour les clés API statiques, utilisez les en-têtes Bearer token pour les jetons à courte durée de vie avec une étape de renouvellement si nécessaire, et utilisez le type d'identifiant OAuth2 Authorization Code pour l'autorisation déléguée de l'utilisateur. Dans tous les cas, stockez les secrets dans les Credentials n8n — jamais en ligne dans les workflows. Le nœud HTTP Request fonctionne avec les trois modèles via son menu déroulant Authentication, ce qui en fait votre solution de repli pour tout service qui n'a pas de nœud n8n dédié.
Point de contrôle de la leçon
Révisez la leçon et recevez des conseils sur votre travail.