OAuth2 générique dans n8n : connecter une API sans node natif

n8n couvre plusieurs centaines d’intégrations avec un node natif, mais le web expose des dizaines de milliers d’API — et la vôtre n’a pas toujours son node dédié. Bonne nouvelle : l’absence de node natif ne bloque rien tant que l’API supporte une authentification standard. Le node HTTP Request, combiné à une credential OAuth2 API générique, permet de vous connecter à n’importe quel service qui expose ce protocole, avec le même niveau de fiabilité qu’un node officiel. Ce guide détaille les trois flux OAuth2 disponibles dans n8n, leur configuration pas à pas, et les pièges qui font perdre le plus de temps la première fois.

Quand une credential OAuth2 générique remplace un node natif

Un node natif n8n (Slack, HubSpot, Notion...) n’est rien d’autre qu’une enveloppe : il pré-configure les URLs OAuth2 du fournisseur et les endpoints de l’API pour vous éviter de les chercher. Rien n’empêche de reproduire exactement ce mécanisme à la main pour une API qui n’a pas cette enveloppe — un CRM métier, un ERP interne, une API SaaS de niche ou votre propre backend d’entreprise. Les deux ingrédients nécessaires : que le fournisseur documente ses endpoints OAuth2 (Authorization URL, Access Token URL) et que le node HTTP Request sache y appeler vos endpoints ensuite, ce qu’il fait nativement — y compris la pagination et les retries en cas de timeout sur les appels qui suivent l’authentification.

Les trois grant types disponibles dans n8n

La credential générique « OAuth2 API » propose un sélecteur Grant Type avec trois options, chacune adaptée à un scénario précis :

• Authorization Code — le flux le plus courant pour connecter le compte d’un utilisateur : un humain est redirigé vers l’écran de consentement du fournisseur, autorise l’accès, puis n8n reçoit un code d’autorisation qu’il échange contre un access token et un refresh token. C’est ce que font en coulisse les nodes Google, Slack ou HubSpot.
• Client Credentials — pas d’utilisateur, pas d’écran de consentement : l’application s’authentifie directement avec son Client ID et son Client Secret pour obtenir un token qui représente l’application elle-même, pas une personne. C’est le flux le plus simple à mettre en place, et le bon choix pour une API interne, un ERP ou une intégration B2B serveur à serveur.
• PKCE (Proof Key for Code Exchange) — une variante durcie d’Authorization Code, où n8n génère un secret temporaire (code verifier) vérifié à l’échange du token, sans exposer de Client Secret fixe. Certaines API l’imposent pour les applications qui ne peuvent pas garder un secret confidentiel de façon fiable.

Si vous ne savez pas lequel choisir, la documentation de l’API cible tranche généralement en une phrase : « server-to-server » ou « machine-to-machine » pointe vers Client Credentials ; « connect your account » ou un écran de consentement dans leurs captures d’écran pointe vers Authorization Code (ou PKCE si mentionné explicitement).

Configurer la credential pas à pas (Authorization Code)

1. Créez une nouvelle credential et cherchez OAuth2 API (catégorie générique, pas liée à un service précis), puis choisissez Grant Type : Authorization Code.
2. Renseignez l’Authorization URL et l’Access Token URL de la documentation de l’API (souvent sous /oauth/authorize et /oauth/token), ainsi que le Client ID et le Client Secret générés côté fournisseur.
3. Renseignez les Scopes nécessaires, séparés par un espace — demandez uniquement ceux dont vos workflows ont réellement besoin, jamais l’ensemble disponible par facilité.
4. Choisissez l’Authentication Type : Header (Client ID/Secret en Basic Auth dans l’en-tête, le plus répandu) ou Body (envoyés dans le corps de la requête token) — la documentation de l’API précise laquelle elle attend.
5. Copiez l’OAuth Redirect URL affichée en bas du formulaire, et collez-la dans la configuration de votre application côté fournisseur (champ « Redirect URI » ou « Callback URL »). Sans cette étape, le fournisseur refuse de rediriger vers n8n après le consentement.
6. Cliquez sur Connect my account : une fenêtre s’ouvre vers l’écran de consentement du fournisseur ; une fois validé, n8n récupère automatiquement l’access token et le refresh token.

Pour une instance self-hosted, l’OAuth Redirect URL dépend directement de N8N_HOST et WEBHOOK_URL : si ces variables ne pointent pas vers votre domaine public en HTTPS, la redirection échoue avant même d’arriver à l’écran de consentement. C’est la cause la plus fréquente d’un flux Authorization Code qui ne se termine jamais en self-hosted.

Client Credentials : le flux le plus simple pour une API interne ou B2B

Pour une API qui ne représente pas un utilisateur mais votre application elle-même, Client Credentials retire deux étapes : pas d’Authorization URL, pas d’écran de consentement dans un navigateur. Choisissez ce Grant Type, renseignez seulement l’Access Token URL, le Client ID et le Client Secret (plus les scopes si l’API en exige), puis cliquez sur Connect my account : n8n appelle directement l’Access Token URL avec vos identifiants et récupère le token, sans redirection.

C’est le flux à privilégier chaque fois qu’il est disponible : moins de surface d’erreur, pas de dépendance à un utilisateur qui doit revalider l’accès si son compte change, et un renouvellement de token entièrement automatique et silencieux.

Brancher la credential sur le node HTTP Request

Une fois la credential créée, direction le node HTTP Request qui appellera réellement l’API :

1. Dans l’onglet Authentication, sélectionnez Generic Credential Type.
2. Choisissez OAuth2 API comme type, puis votre credential dans la liste.
3. Configurez l’URL, la méthode et les headers de la requête comme pour n’importe quel appel HTTP Request classique — n8n ajoute automatiquement le token OAuth2 dans l’en-tête Authorization, et le renouvelle tout seul via le refresh token quand il expire (pour Authorization Code) ou en redemandant un nouveau token (pour Client Credentials).

Le même sélecteur Generic Credential Type propose aussi Basic Auth, Header Auth, Query Auth, Digest Auth et OAuth1 pour les API qui n’exigent pas OAuth2 — inutile de complexifier une simple clé API en en-tête avec un flux OAuth2 si Header Auth suffit.

Pièges courants qui font perdre du temps

• Callback URL non HTTPS en self-hosted : la plupart des fournisseurs OAuth2 refusent une Redirect URL en http:// — vérifiez que votre instance est exposée en HTTPS avant de configurer Authorization Code, voir notre guide HTTPS avec Traefik ou Caddy si ce n’est pas déjà fait.
• Scope ajouté après coup : modifier le champ Scope d’une credential déjà connectée ne suffit pas, il faut recliquer sur Connect my account — un token déjà émis ne peut pas être élargi rétroactivement.
• PKCE oublié quand l’API l’impose : une erreur peu explicite (invalid_request ou code_challenge required) sur l’échange de code signale souvent qu’il fallait choisir PKCE plutôt qu’Authorization Code.
• Authentication Type Header vs Body inversé : une erreur invalid_client vient souvent de ce réglage mal choisi plutôt que d’un Client ID ou Secret erroné — le premier réflexe à vérifier avant de régénérer des identifiants inutilement.
• Refresh token qui expire silencieusement : une credential générique peut se retrouver avec un refresh token révoqué côté fournisseur, provoquant une erreur invalid_grant sur tous les workflows qui en dépendent — notre guide pour surveiller l’expiration des tokens OAuth s’applique à l’identique.

Sécurité : une API supplémentaire, c’est un secret supplémentaire à protéger

Ajouter une credential OAuth2 générique revient à donner à n8n les moyens d’agir en votre nom sur un système externe. Une étude de référence de Sun et Beznosov, présentée à l’ACM CCS 2012 (The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems, plus de 900 citations), montre que la majorité des failles observées sur des déploiements OAuth réels ne viennent pas du protocole lui-même mais d’erreurs d’implémentation : scopes trop larges, vérification insuffisante du paramètre state, confusion entre les rôles d’un token. Le protocole est solide ; c’est la configuration qui ne pardonne pas.

Trois réflexes limitent le risque avec une credential générique : demandez le scope le plus restreint possible pour chaque usage plutôt que le plus large « au cas où » — un token de lecture seule qui fuit est bien moins grave qu’un token avec accès en écriture complet ; ne dupliquez jamais un Client Secret en dur dans un node Code, passez toujours par la credential, le même principe que pour sécuriser les credentials n8n en général ; et documentez chaque credential générique créée (à quoi elle sert, quel workflow en dépend), comme détaillé dans notre guide de gestion des credentials via l’API n8n pour qui provisionne plusieurs instances.

OAuth2 générique vs clé API : lequel choisir

Critère	OAuth2 générique	Clé API simple (Header/Query Auth)
Complexité de mise en place	Plus élevée (URLs, scopes, redirect)	Minimale (coller la clé)
Représente un utilisateur précis	Oui (Authorization Code)	Non
Renouvellement du secret	Automatique (refresh token)	Manuel, à la révocation
Granularité des permissions	Fine (scopes)	Souvent tout ou rien
Exigé par l’API cible	Quand l’API ne propose que ça	Quand l’API le propose en alternative

Si l’API cible propose les deux, une clé API statique via Header Auth reste plus simple à opérer pour un usage interne à faible enjeu ; réservez OAuth2 générique aux cas où l’API l’impose, où plusieurs utilisateurs doivent connecter leur propre compte, ou où la granularité des scopes compte vraiment.

Pour aller plus loin

Cette mécanique OAuth2 générique est exactement ce qui permet d’étendre un pipeline RAG au-delà de Notion ou Google Drive : n’importe quelle API documentaire d’entreprise qui expose OAuth2 peut alimenter la même chaîne d’ingestion et de vectorisation, sans attendre qu’un node natif existe. Pour un usage où la piste d’audit compte — savoir qui a connecté quelle credential et quand — le Pack Conformité & Audit journalise ce type d’événement dans Supabase au-delà de ce que n8n conserve nativement.

En résumé

L’absence de node natif ne doit jamais être un mur : le node HTTP Request et la credential OAuth2 API générique de n8n couvrent Authorization Code, Client Credentials et PKCE avec la même fiabilité qu’une intégration officielle. L’essentiel tient en quelques réglages bien compris — la bonne Redirect URL en HTTPS, l’Authentication Type qui correspond à ce qu’attend l’API, des scopes aussi restreints que possible — et en une hygiène de credential identique à celle de n’importe quel autre secret sensible dans votre instance.