n8nの認証情報は、接続先が指定する方式に合わせてCredentialsへ保存し、使うノードから選択します。サービス専用のCredentialが用意されているなら、まず対応する設定を確認してください。
汎用OAuth2を使う場合は、grant type、認可・トークンのURL、scope、クライアント認証方式、redirect URIの照合が出発点です。保存や認可が終わった後も、意図したアカウントで必要なデータを読めるかまで確かめましょう。
Credentialsで何を管理する？
Credentialsは、外部のAPIやデータベースへ接続するための認証情報を管理する仕組みです。サービスごとのAPIキーやOAuth2の情報を保存し、ワークフロー内のノードで利用します。
一つの接続設定を複数のノードで使うときも、どのCredentialを選んでいるかを追える形が基本です。n8nへのログインとは分けて、外部サービスのデータを操作する権限を確かめましょう。
認証方式は接続先の指定から選ぶ
APIキーとOAuth2は、設定が簡単そうな方を自由に選べるとは限りません。利用するAPIが受け付ける方式、実行したい操作、サービス専用Credentialの対応を先に照合してください。
n8n公式も、対応するサービスではPredefined Credential Typeの利用を勧めています。汎用設定では認可URLなどを手入力する場面が増えるため、専用の設定で目的を満たせるかを先に見て、確認する項目を絞りましょう。
APIキー・OAuth2・n8nのログインを分ける
| 方式 | 何を使うか | 最初に確認すること |
|---|---|---|
| APIキーなど | 接続先が発行したキー。誰の権限かは提供元の設計による | 発行元、許可された操作、送信先、期限、失効方法 |
| OAuth2 Authorization Code／PKCE | 利用者の認可を経て取得するaccess token | アプリ登録、認可アカウント、scope、redirect URI |
| OAuth2 Client Credentials | アプリ自身に許可された範囲のaccess token | アプリの資格情報、token URL、クライアント認証方式 |
| n8nのログイン／SSO | n8n内へ入るための利用者認証 | 外部サービス用Credentialsとは別に管理 |
OAuth2の中心は、外部リソースを使う権限の認可です。Client Credentialsのように、個人のブラウザで同意する流れを前提にしない方式もあります。
また、検索語にある「OAuth」がOAuth1を指す場合は、OAuth2の設定値を流用できません。この記事ではOAuth2を扱い、OAuth1固有の署名や設定は接続先の対応資料で確認する範囲とします。
認証情報を作り、使うノードへ指定する
Credentialの作成では、まず保存先を決めてください。目的のノードで接続を選び直し、限定した操作で確認するまでを一つの手順として進めましょう。
以下は2026年10月31日に確認した公式仕様に基づく設定の進め方です。画面の配置や選択肢はn8n本体版・ノード版・プランで変わるため、実際の環境では版と権限を記録したうえで照合します。
接続先と用途、保存先を決める
最初に「どのサービスの、どの環境で、何をする接続か」を短く書き出しましょう。たとえばsample-read-test-contentteamは、架空のサービスで読み取り用・検証環境・担当チームを識別する命名例です。
名前にキー、secret、個人のメールアドレスを埋め込む必要はありません。秘密の値とは別に、所有者、使うワークフロー、必要権限、期限の有無、更新担当を台帳へ記すと、担当交代でも判断しやすくなります。
- 環境と変更権限を確認する
Cloudかself-hostedか、プラン、本体版、対象ノードの版、利用者の役割が確認項目です。接続先のキー発行やアプリ登録についても、変更できる権限を持つ担当者を確認してください。
- Credentialsの作成画面を開く
公式ドキュメントではCreateからCredentialを作るほか、ノードのCredential選択欄から新規作成する方法が案内されています。プロジェクト対応環境では個人領域か対象プロジェクトを選び、表示中の保存先を確かめましょう。
- 対応する種類で保存する
サービス専用の種類を先に確認し、必要な場合に汎用方式を選択します。用途が分かる名前を付け、接続先公式が求める値だけを専用欄へ入力してください。
- ノードに割り当てて確認する
ワークフローの対象ノードで、作成したCredentialを選びます。同名の検証用・本番用を取り違えていないかも照合しましょう。
APIキーは専用欄へ入れ、送信先を確かめる
架空のAPIがX-API-Keyというヘッダーでキーを求める場合を考えます。汎用Header Authなら、NameへX-API-Key、Valueへテスト用のキーを入力する構成です。
ここで示す<TEST_API_KEY>は説明用の仮値で、実際に通るキーではありません。接続先がAuthorization: Bearer …を指定するなら、ヘッダー名や接頭辞をその仕様へ合わせます。
対応するCredentialのAllowed HTTP Request Domainsは、HTTP Requestノードから利用できる送信先を限定する機能です。ただし、そのサービス専用ノードには作用しない制約なので、すべての送信を一括で制御する機能と考えてはいけません。
送信先の制限と、接続先で与える権限は別の設定です。キーの読み書き権限と、どのドメインへ送るかの両方を見てください。
保存時の確認と実操作の確認を分ける
公式ドキュメントでは保存時にCredentialをテストすると案内しています。そこで確認できる範囲と、ワークフローが必要とする操作の範囲は同一とは限りません。
たとえば接続自体が認められても、目的のフォルダーやデータを読む権限が不足する場合があります。ノードへ割り当てた後は、提供元が読み取りと定める操作でテスト用データ1件を取得し、対象IDと必要な項目を照合しましょう。
保存成功・認可完了・目的操作の成功は分けて記録します。GETという名前だけで無料・副作用なしとは判断せず、APIの料金や上限も実行前に確かめてください。
OAuth2の設定はgrant typeから確認する
汎用OAuth2は、まず接続先が要求するgrant typeを確定させます。その後に入力欄と公式資料を対応させて、不要な認可URLを探したり、別環境の情報を混ぜたりする誤りを減らしましょう。
Authorization Code・PKCE・Client Credentialsを選び分ける
Authorization Codeは、利用者の認可後に得たコードをaccess tokenへ交換する流れです。PKCEはその認可コードを保護する拡張で、n8nの汎用OAuth2ではGrant Typeの選択肢として扱われています。
接続先がPKCEを求める場合は、その対応とアプリの種類を確認してください。PKCEを選んだことだけを理由に、Client Secretを不要と決めつけることはできません。
Client Credentialsは、アプリが自身に許可されたリソースへアクセスする方式です。通常の説明で利用者の同意画面やredirect URIを必須手順にせず、token URL、Client ID、Client Secret、認証方式などを提供元仕様と合わせます。
確認の入口は、自分のテスト用データを利用者の許可で読むならAuthorization Code／PKCE、アプリの権限で読むAPIならClient Credentials、という区別です。最終的な選択は、利用するAPIと登録アプリが対応する方式に従ってください。
URL・scope・認証方式を公式資料で埋める
| n8n側の項目 | 取得・照合する先 | 間違えやすい点 |
|---|---|---|
| Grant Type | 接続先のOAuth／API公式資料とアプリの種類 | 最初に確定し、他方式の設定を混ぜない |
| Authorization URL | 該当サービス・tenant・regionの認可endpoint | 利用者認可がある方式で使う。データ取得URLとは別 |
| Access Token URL | 接続先の公式token endpoint | 末尾を推測せず、対象環境を合わせる |
| Client ID／Client Secret | 接続先で登録した対象アプリ | 開発用と本番用、失効前後の値を取り違えない |
| Scope | 目的操作に必要な権限の公式一覧 | 文字列、区切り、追加認可の条件は提供元ごとに照合 |
| OAuth Redirect URL | 設定中のn8nが表示する値 | 接続先アプリの登録値と一致させる |
| Authentication | token endpointに対するクライアント認証の指定 | Header／Bodyは提供元に合わせる。後のAPIへのBearer送信とは別段階 |
| 追加queryなど | 接続先が明示的に要求する条件 | 他サービスのoffline指定などを一律に足さない |
Scopeが任意入力でも、空欄が最小権限を意味するとは限りません。n8nの汎用Authorization Code／PKCEの説明には、未指定だとクライアントで利用可能なscopeを要求する旨があるため、必要な読み取り範囲を明示できるか確認しましょう。
認可画面で、目的にない書き込みや管理権限まで求められた場合は、そのまま同意せず設定と提供元資料へ戻ります。権限を増やしてエラーを消す前に、そもそも読みたい対象と操作が合っているかを確かめてください。
Redirect URIを一致させ、正しいアカウントで認可する
利用者の認可を伴う方式では、Credentialに表示されたOAuth Redirect URLを、接続先のアプリ登録へそのまま照合します。検証環境と本番環境、httpsとhttp、ホスト名、パス、末尾の違いを勝手に省略しないでください。
これはWebhookの受信用URLとは別です。n8nの公開URLを変更したり別環境へ移したりした場合も、新しい表示値と接続先の登録内容を確認する必要があります。
認可へ進んだら、ブラウザで選ばれているアカウントと要求権限を読み取ってください。複数アカウントを使っている人は、普段のログイン先がそのまま選択されていないかに注意しましょう。
URIの不一致や証明書エラーを、Ignore SSL Issuesの有効化で解決する手順にはしません。接続先の登録値、n8nの公開URL、証明書の設定を担当者と照合してください。
認可後は読み取りで接続先を確かめる
認可画面が閉じただけでは、目的のデータへ接続できたかは分かりません。先に用意したテスト対象を一つ選び、読み取り操作でアカウント・対象ID・必要フィールドを照合しましょう。
ここで扱うのは、テスト用データ1件を読むという未実行の確認例です。Google SheetsやGmailなどでは、提供元固有のアプリ登録・scope・対象データの権限を、それぞれの連携手順と合わせて確認します。
空の結果が返る場合は、対象が本当に空なのか、検索条件やリソースの指定が違うのかを確認してください。認証失敗とデータなしを分ければ、不要な再認可や権限追加を避けやすくなります。
認証エラーは段階ごとに切り分ける
エラーが出たら、作成、認可、token取得、API操作のどこで止まったかを分けてください。最初に失敗した段階へ戻ると、無関係な設定まで変更せずに確認を進められます。
| 止まる段階 | 確認する候補 | 次の行動 |
|---|---|---|
| 作成画面・保存先の選択 | 選んだCredentialの種類、入力必須項目、プロジェクト権限 | 対象環境と作成権限を確認 |
| 認可画面へ進む前後 | 認可URL、grant type、redirect URI、利用可能なテストユーザー | 接続先のアプリ登録と照合 |
| token取得 | Client ID／Secret、token URL、Header／Bodyの指定、secretの失効 | 同じアプリ・同じ環境の値かを確認 |
| APIでデータを読む | token期限、scope、対象権限、endpoint、API有効化、ネットワーク | 接続先のエラー説明と最小読み取りを照合 |
リダイレクトやクライアント情報が合わない
redirect URIの不一致なら、現在開いているn8nの表示値とアプリ登録を比較してください。Client IDとSecretの組み合わせも、同じアプリから取得したものかを確認します。
Secretを更新した直後なら、Credentialに古い値が残っている可能性も確認対象です。複数項目を一度に変えると原因が追えなくなるため、一つの不一致を修正して再確認する順で進めましょう。
tokenはあるのに操作できない
tokenを取得できても、対象フォルダーの共有権限、必要scope、呼び出すAPIの種類が一致しなければ操作できない場合があります。401や403という数字だけで、期限切れや権限不足を確定しないでください。
記録するのは、失敗した段階、操作名、日時、秘密を除いたエラーコード、テスト対象の識別情報です。Authorizationヘッダー、token、Client Secretを含むリクエスト全文や画面を、そのまま相談先へ公開しないようにしましょう。
認証項目に不一致が見つからなければ、endpoint、API利用条件、ネットワークなどへ確認を広げます。課金上限や回数制限の問題を、認証方式の変更で直そうとしないことも大切です。
期限・再認可・キー更新を管理する
APIキーの交換、access tokenの更新、利用者による再認可は、別の作業として管理します。初回接続に成功しても、いつまで使えるか、失効時に誰が直すかまでは確定しません。
APIキーを交換するときは利用先を洗い出す
キーを交換する前に、同じ接続を使っているワークフローと担当者を確認してください。共有中のCredentialを直接書き換えると、想定していなかった処理にも影響が及びます。
提供元が新旧キーの併用を許すなら、検証用の新Credentialで最小読み取りを確認し、対象ノードを順に切り替えるのが一つの方法です。古いキーの失効は、残っている利用先がないかを照合してから実施しましょう。
この切り替え方は運用上の提案で、全サービスが同時に複数キーを発行できるという意味ではありません。漏えいが疑われる場合は旧キーを戻し先に使わず、提供元の失効・再発行手順を優先してください。
OAuth2の更新を無期限の接続保証にしない
refresh tokenは、新しいaccess tokenを得るための情報です。ただしOAuth2の基本標準では発行が任意であり、Client Credentialsでは通常refresh tokenを含めない扱いになっています。
そのため「OAuth2なら一度認可すれば永久に自動更新する」とは判断できません。提供元がrefresh tokenを発行するか、その有効期限や失効条件、アプリ設定の変更時に何が必要かを確認しましょう。
scopeの追加、認可の取り消し、アプリの状態変更などによって、再認可が必要になる場合もあります。全サービス共通の「7日」「30日」といった期限を当てはめず、対象サービスの条件を記録してください。
短時間の読み取りしか試していないなら、記録は「初回接続確認、期限後の更新は未確認」とします。更新確認のために本番tokenを意図的に失効させず、提供元が認める検証方法とテスト環境を使いましょう。
共有は秘密の表示と権限の利用を分けて考える
Credentialを共有するときは、秘密の値を見せるかだけでなく、その認証で外部の何を操作できるかを確認します。画面でキーが読めなくても、共有された接続を使えることの影響までなくなるわけではありません。
値が非表示でも、外部操作に使う権限は渡るという見方が必要です。これは、共有相手が認証情報の詳細を表示・編集できなくても、ワークフローの実行などに利用できる仕様から導ける判断になります。
プラン・役割・共有先を確認する
2026年10月31日に確認したCredential共有の公式ドキュメントでは、Cloudは全プラン、self-hostedはBusiness・Enterpriseが対象です。Communityで同じ共有機能を使える前提にはせず、実契約と画面も照合してください。
自分が所有するCredential、プロジェクト所有のCredential、instanceの管理者権限では、共有を操作できる条件が異なります。特にチームプロジェクトで利用できるかは共有とプロジェクトの役割に従うため、管理者なら常に無条件で使えるとは考えないようにしましょう。
共有操作は、対象CredentialのSharingでユーザーまたはプロジェクトを選び、Saveする流れです。受け手のCan useは、実行・公開に利用できても詳細を表示・編集できない役割なので、名前だけで編集権限まであると判断しないでください。
たとえば読み取り専用のテスト接続を必要なチームへ渡すなら、提供元側でも権限を読み取りに絞り、受け手が対象データだけを取得できるか確認します。書き込み権限付きの個人接続を、そのまま広いプロジェクトへ共有する判断とは分けましょう。
確認先はCredentialのSharingだけではありません。ワークフロー共有でも、編集者がそのワークフロー内のCredentialを利用できる場合があるため、ワークフローの共有先と実行可能な操作も合わせて点検してください。
異動や退職の際は、n8n側の共有解除に加え、外部サービス側の権限や認可も見直します。共有を外したことだけで、過去に取得されたデータや提供元の認可まで取り消されたとは限りません。
FixedとEnd-user credentialsを混同しない
OAuthのFixed credentialは、誰が実行しても同じCredentialを使う方式です。End-user credentialでは、各利用者が自身のアカウントを接続して実行するため、接続そのものを全員で共有する考え方とは異なります。
この選択肢は公式ドキュメント上、Cloud Enterprise／self-hosted EnterpriseのOAuthが対象です。一般プランにも必ず表示される項目として探す必要はありません。
さらに、確認時点のEnd-user credentialsはPreviewです。公式は本番ワークフローで依存しないよう案内しているため、利用を検討する場合は、チームプロジェクトでの作成や対応するトリガーなどの条件をEnd-user credentialsの公式説明で確認してください。
チーム共通のサービス用接続を使うのか、一人ずつ自身のデータを扱うのかを先に決めましょう。n8n管理画面へ入るSSOの設定とも別の判断です。
別環境へ移すときは接続と権限を再確認する
初めて環境を移すときは、移行先でCredentialを再作成・再認可し、ノードから選び直す方法を基本の確認経路にできます。ワークフローの形が再現されたことと、使える認証情報がそろったことは分けて考えてください。
ワークフロー移動だけで認証完了としない
移したデータにCredentialの名前やIDがあっても、それだけで接続先へアクセスできるとは限りません。また、普通の項目へ直接書いたヘッダーや貼り付けた設定に秘密が残る可能性があるため、JSONを第三者へ渡す前の内容確認も必要です。
n8n packagesは、公式ドキュメント上ではn8n 2.27.0以降のPreview機能として案内されています。CredentialのID・名前・種類の参照は運びますが、秘密やホスト・regionなどのCredential設定は含めないため、移行先側の準備を省く理由にはなりません。
パッケージの形式や機能は変わり得るので、本体版と利用方法を確認してください。初級の接続確認では、次の順番で一つずつ照合します。
- 移行先用の接続を準備する
利用するアカウント、環境、必要scope、所有者を整理してから、Credentialを作成・認可してください。OAuth Redirect URLが変わる場合は、接続先の登録値も照合しましょう。
- ノードと共有範囲を確認する
対象ノードから正しいCredentialを選び、移行元の名前が残っているだけで完了としません。実行担当が利用できる権限も別途確かめてください。
- テスト用データを読み戻す
意図したアカウント・対象ID・必要フィールドを照合します。読み取り確認の後も、自動で公開やスケジュール実行へ進めず、運用開始の判断を分けましょう。
セルフホストの秘密移行は管理者手順へ分ける
self-hostedには、Server CLIでCredentialsをexport／importする管理者向けの経路もあります。ただし平文出力では秘密がファイル内に見え、同じIDの取り込みは既存データの上書きにつながる操作です。
構築や復元の実装は、Docker・永続化・バックアップを扱う管理手順で確認する範囲です。ここではコマンドをそのまま実行する例を置かず、接続を再作成する経路と、秘密を移行する管理作業の違いを押さえます。
検証後に作成したCredentialを片付ける場合も、他の利用先がないか確認してから解除・削除してください。共用の接続や外部キーを試行錯誤で失効させず、テスト用の認可は提供元が定める取り消し手順で戻しましょう。
まとめ｜認証方式を合わせ、接続と利用権限を確かめる
n8nのCredentialsは、接続先に合う認証方式を選び、専用欄へ情報を保存してノードから使うためのものです。OAuth2ではgrant typeと設定元をそろえ、認可完了後に対象アカウントと最小限の読み取りを確かめます。
最初の一歩は、一つのテスト接続について「用途・権限・期限・担当者」を整理することにしましょう。作成、ノードへの割り当て、テストデータの照合まで進めたら、期限後の更新や共有先の確認結果は別に記録してください。
接続できた瞬間よりも、誰がどの権限で使い続けるかを追える状態の方が、運用判断では大切だと考えます。秘密の非表示だけに頼らず、利用できる外部操作と更新責任まで見える形に整えましょう。