简介

绝大多数真实场景的 API 都会拒绝未经身份验证的请求。在你从 Stripe 拉取数据、向 Slack 发送消息或查询 CRM 之前，你需要证明自己的身份。n8n 通过其凭据（Credentials）系统来处理这一点——这是一个安全的加密存储，可以将密钥排除在工作流 JSON 之外，并允许你在多个节点之间复用同一套身份验证配置。

本课涵盖你在至少 80% 的集成中会遇到的三种模式：作为请求头传递的 API 密钥、Bearer 令牌，以及 OAuth2 授权码流程。学完之后，你将掌握如何在 n8n 中配置每一种模式，以及在目标服务没有现成内置节点时，如何将其接入 HTTP Request 节点。

API 密钥与自定义请求头

最简单的身份验证模式：服务方会为你签发一个静态密钥，你在每次请求时发送它，通常作为自定义请求头（如 X-API-Key）或作为查询参数。

在 n8n 中，前往 Credentials > Add Credential > Header Auth。你只需填写一次请求头名称和值，n8n 就会在使用该凭据的每个请求中自动注入它。

示例：连接一个要求在请求头中携带密钥的天气 API。

在 HTTP Request 节点中，将 Authentication 设为 Header Auth，选择你保存的凭据，然后配置请求：

{
  "method": "GET",
  "url": "https://api.weatherapi.com/v1/current.json",
  "qs": {
    "q": "Hanoi"
  }
}

n8n 会自动附加该请求头——你无需在节点本身中硬编码密钥。如果 API 要求将密钥作为查询参数传递（例如 ?apikey=...），则改用 Query Auth 凭据类型代替 Header Auth。思路相同，位置不同。

一个常见的错误是将密钥直接粘贴到 Set 节点或 URL 字段中。这样会把密钥嵌入到工作流 JSON 中，进而被导出、纳入版本控制乃至共享。请始终使用 Credentials。

Bearer 令牌

许多 API——尤其是遵循 OAuth2 客户端凭据模式或签发短生命周期 JWT 的 API——期望接收如下格式的 Authorization 请求头：

Authorization: Bearer <token>

在 n8n 中，这仍然是 Header Auth 凭据。将 Name 字段设为 Authorization，将 Value 字段设为 Bearer 后跟一个空格再加上你的令牌：

Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

如果你的令牌会过期且需要以编程方式刷新，可以添加一个前置的 HTTP Request 节点来调用令牌端点，使用类似 {{ $json.access_token }} 的表达式从响应中提取 access_token，然后将其传入下一个节点的 Authorization 请求头。这样就构成了一个无需编写自定义代码的简易两节点令牌刷新模式。

OAuth2 授权码流程

使用授权码模式的 OAuth2 更为复杂，因为它需要浏览器重定向——用户必须访问提供方、登录并授予权限，然后 n8n 才能收到访问令牌。n8n 会自动化处理其中大部分环节。

第 1 步：创建 OAuth2 API 凭据。前往 Credentials > Add Credential > OAuth2 API。根据你在提供方一侧注册的应用填写相应字段：

{
  "Grant Type": "Authorization Code",
  "Authorization URL": "https://accounts.google.com/o/oauth2/auth",
  "Access Token URL": "https://oauth2.googleapis.com/token",
  "Client ID": "your-client-id",
  "Client Secret": "your-client-secret",
  "Scope": "https://www.googleapis.com/auth/spreadsheets"
}

第 2 步：设置重定向 URI。n8n 会显示其回调 URL（类似 https://your-n8n-instance.com/rest/oauth2-credential/callback）。将其复制到提供方仪表盘中你 OAuth 应用配置的 Authorized Redirect URIs 字段。

第 3 步：在 n8n 中点击 Connect my account。系统会弹出一个浏览器窗口，你登录并授权后，n8n 会自动存储得到的访问令牌和刷新令牌。从此时起，n8n 也会静默地处理令牌刷新——当访问令牌过期时，它会使用刷新令牌获取新令牌，整个过程无需你任何操作。

对于 Google Sheets、Slack 或 HubSpot 等内置节点，n8n 会预填 Authorization URL 和 Access Token URL——你只需从提供方文档中获取 Client ID、Client Secret 以及 scope 列表。

常见错误及修复方法

401 Unauthorized 几乎总是意味着凭据配置错误或令牌已过期。请确认请求头名称与 API 文档完全一致——有些 API 使用 X-Auth-Token，有些使用 api-key（小写），这种不匹配在运行前是看不出来的。

403 Forbidden 表示令牌有效，但缺少所需的 scope。请返回你的 OAuth 应用配置，添加缺失的 scope，然后重新授权。n8n 不会自动重新请求新的 scope。

如果 OAuth2 连接失败并出现 redirect_uri_mismatch 错误，说明 n8n 中的回调 URL 与提供方注册的 URL 不完全一致——请检查末尾斜杠或 http 与 https 的差异。

切勿在工作流表达式或节点参数中存储密钥。n8n 使用实例加密密钥对 Credentials 存储中的所有内容进行加密。如果需要轮换密钥，只需在凭据中更新一次，所有使用该凭据的工作流就会立即应用新值。

小结

对静态 API 密钥使用 Header Auth；对短生命周期令牌使用 Bearer 令牌请求头（如有需要可加入刷新步骤）；对委托的用户授权使用 OAuth2 授权码凭据类型。在任何情况下，都应将密钥存储在 n8n Credentials 中——切勿内联到工作流里。HTTP Request 节点通过其 Authentication 下拉菜单支持上述所有模式，因此当你对接的服务没有专用 n8n 节点时，它就是你的万能备选方案。