はじめに

実際のAPIのほとんどは、未認証のリクエストを拒否します。Stripeからデータを取得したり、Slackに投稿したり、CRMに問い合わせたりする前に、自分の身元を証明する必要があります。n8nはこれをCredentials（認証情報）システムを通じて処理します — これは、ワークフローのJSONから秘密情報を除外し、複数のノードで同じ認証設定を再利用できるようにする、安全で暗号化された保存場所です。

このレッスンでは、統合の少なくとも80%で遭遇する3つのパターンを扱います。ヘッダーとして渡される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=...）、Header Authの代わりにQuery Auth認証タイプを使用してください。考え方は同じで、配置場所が異なるだけです。

よくある間違いは、キーをSetノードやURLフィールドに直接貼り付けることです。そうすると、ワークフローJSON内に秘密情報が埋め込まれ、エクスポート、バージョン管理、共有されます。常にCredentialsを使用してください。

Bearerトークン

多くのAPI — 特にOAuth2クライアントクレデンシャルに従うものや、短命なJWTを発行するもの — は、次の形式のAuthorizationヘッダーを期待します：

Authorization: Bearer <token>

n8nでは、これもHeader Auth認証情報です。NameフィールドをAuthorizationに、ValueフィールドをBearerの後にスペースとトークンを続けて設定します：

Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

トークンが期限切れになりプログラムで更新する必要がある場合は、トークンエンドポイントを呼び出す先行HTTP Requestノードを追加し、{{ $json.access_token }}のような式でレスポンスからaccess_tokenを抽出し、次のノードのAuthorizationヘッダーに渡します。これにより、カスタムコードなしでシンプルな2ノードのトークン更新パターンが作成されます。

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、プロバイダードキュメントのスコープリストだけです。

一般的なエラーと修正方法

401 Unauthorizedは、ほぼ常に認証情報の設定ミスまたはトークンの期限切れを意味します。ヘッダー名がAPIドキュメントの指定と完全に一致していることを確認してください — 一部のAPIはX-Auth-Tokenを使用し、他のものはapi-key（小文字）を使用しており、この不一致は実行時までわかりません。

403 Forbiddenは、トークンは有効だが必要なスコープが不足していることを意味します。OAuthアプリに戻り、不足しているスコープを追加して再認可してください。n8nは新しいスコープを自動的に再要求しません。

OAuth2 Connectがredirect_uri_mismatchエラーで失敗した場合、n8nのコールバックURLとプロバイダーに登録されているURLが正確に一致していません — 末尾のスラッシュやhttpとhttpsの違いを確認してください。

ワークフロー式やノードパラメータに秘密情報を絶対に保存しないでください。n8nはインスタンスの暗号化キーを使用してCredentials内のすべてを暗号化します。キーをローテーションする必要がある場合は、Credential内で一度更新すれば、それを使用しているすべてのワークフローが即座に変更を取得します。

まとめ

静的APIキーにはHeader Authを、短命なトークンで必要に応じて更新ステップを伴う場合はBearerトークンヘッダーを、委任されたユーザー認可にはOAuth2 Authorization Code認証タイプを使用してください。すべての場合において、秘密情報はn8n Credentialsに保存し、ワークフロー内にインラインで記述しないでください。HTTP RequestノードはAuthenticationドロップダウンを通じて3つのすべてのパターンで動作するため、専用のn8nノードがないサービスのフォールバックになります。