场景导入：别让“认证”卡住你的自动化流水线
笔者在 N8N大学 经常遇到这样的朋友：流程图画得飞起，逻辑理得通顺，结果一到调用外部 API 的环节就卡壳了。看到 401 Unauthorized 或者 Invalid Token 就头皮发麻。
坦白讲，手动复制粘贴 API Key 也许能应付一两次测试，但一旦遇到需要定期刷新的 OAuth2，或者密钥泄露重置，你的自动化流程就会瞬间瘫痪。这不仅仅是技术问题，更是效率的黑洞。今天，我们就来一次彻底的“通关”，手把手教你搞定 n8n 中最核心的两个认证方式：API Key 和 OAuth2。
准备工作：磨刀不误砍柴工
在开始之前，我们需要确认几样硬性条件，确保不会因为环境问题导致后续报错：
- 一个运行中的 n8n 实例：可以是官方云服务，也可以是 Docker 部署的本地环境。
- 目标 API 的访问权限：这里我们以 HTTP Request 节点为例，你需要准备好一个支持 API Key 或 OAuth2 的接口（例如 Postman Echo、OpenWeatherMap 等）。
- 开发者凭证：无论是 API Key 还是 OAuth2 的 Client ID/Secret，都要先在第三方平台申请好。
核心实操：搞定 API Key 认证
API Key 是最简单、最直接的认证方式，通常用于服务端对服务端的通信。
步骤一：添加 HTTP Request 节点
首先，在你的 n8n 工作流中添加一个 HTTP Request 节点。这是 n8n 连接外部世界的万能钥匙。
步骤二：设置认证参数
大多数 API Key 需要放在 Header 中传递。在节点配置面板中：
- 选择请求方式（GET/POST）。
- 点击 Authentication 下拉菜单，选择 Generic Credential Type。
- 在下方的 Header Auth 中，输入你的 API Key 名称（通常是
Authorization或X-API-Key）以及对应的密钥值。
笔者提示：有些 API 会在 Header 中使用 Bearer 前缀（例如 Bearer sk-123456），有些则是直接填入 Key。请务必查阅目标 API 的官方文档。
步骤三：测试连接
配置完成后，点击 Execute Node。如果设置正确，你应该能收到 200 OK 的响应以及期望的数据。如果返回 403 Forbidden，请检查 Key 是否复制完整，或者是否有 IP 白名单限制。
核心实操：征服 OAuth2 认证
OAuth2 比 API Key 复杂，因为它涉及到“授权码”的交换过程，通常用于需要用户登录授权的应用（如 Google Sheets、Slack 等）。但在 n8n 中，它被极度简化了。
步骤一：理解 OAuth2 的核心逻辑
你不需要手写 OAuth2 的握手流程。n8n 充当了中间人的角色，你只需要提供 Client ID 和 Client Secret，n8n 会自动处理 Token 的获取和刷新。
步骤二：创建 OAuth2 凭证
- 在 HTTP Request 节点的 Authentication 选项中，选择 OAuth2 API。
- 点击 Create New，进入凭证配置界面。
- 填写 Client ID 和 Client Secret。
- 最关键的一步：设置 Scope（权限范围）。根据你的业务需求，填写对应的权限（例如
read:users write:posts），用空格或逗号分隔。
步骤三：完成授权握手
在凭证设置页面底部，你会看到一个 Connect My Account 按钮。点击它，n8n 会弹出一个授权窗口（或者生成一个链接），引导你登录第三方服务并同意授权。
授权成功后，n8n 会自动获取 Access Token 并保存在凭证中。之后，你在工作流中使用该凭证时，n8n 会自动在 Header 中添加 Authorization: Bearer [token]。
避坑指南：实战中的拦路虎
根据 N8N大学 的实战经验，以下两个坑最容易让人栽跟头：
1. 回调地址 (Callback URL) 不匹配
这是 OAuth2 最常见的报错原因。在第三方平台（如 GitHub、Google Cloud Console）注册应用时，必须将 n8n 生成的回调 URL 粘贴到后台。
常见回调 URL 格式：
http(s)://你的n8n域名/rest/oauth2-credential/callback
如果你是本地运行，通常是 http://localhost:5678/rest/oauth2-credential/callback。
避坑点： 哪怕域名后多了一个斜杠 /，或者协议写成了 https 但实际是 http，都会导致 redirect_uri_mismatch 错误。
2. Token 过期与刷新失败
OAuth2 的 Token 是有有效期的。如果你发现工作流运行一段时间后突然失效，可能是因为 n8n 没有成功刷新 Token。
原因分析： 某些服务（如 LinkedIn 或特定的自定义 API）在刷新 Token 时对 Scope 有严格要求，或者需要重新授权。
解决方案： 在 n8n 的凭证设置中，检查是否开启了 Scope 字段。如果 API 要求刷新时必须携带 Scope，你需要确保填写的 Scope 与获取 Token 时完全一致。
FAQ 问答
Q1: API Key 和 OAuth2 到底该选哪个？
笔者建议： 如果是服务端对服务端的内部通信，优先使用 API Key，因为它简单且稳定。如果涉及用户数据、第三方账号操作（如读取用户的 Gmail），必须使用 OAuth2，这是安全标准。
Q2: 为什么我填了凭证，HTTP Request 节点还是报错？
请检查节点内部的配置。即使添加了凭证，某些 API 还需要在 URL 或 Body 中传递特定的参数。另外，确保你的 n8n 实例能访问目标 API 的服务器（检查防火墙或网络代理设置）。
Q3: 我可以复用 n8n 的凭证吗？
当然可以！这是 n8n 的一大优势。你创建一个名为“Google Maps API”的凭证，可以在工作流的任意多个节点中调用它。一旦凭证更新（如密钥重置），所有使用该凭证的节点都会自动生效，无需逐个修改。
总结与资源
API 集成是 n8n 自动化流程的血管，而认证则是保证血液安全流动的心脏。掌握 HTTP Request 节点的凭证配置，你就能打通绝大多数第三方服务的任督二脉。
如果你在实战中遇到了具体的报错代码，欢迎前往 N8N大学 的社区板块发帖，我们有专门的“排雷”板块帮你解决。
推荐进阶阅读：
- n8n HTTP Request 节点深度解析
- OAuth2 常见报错代码大全
