n8nで外部サービスへ接続すると、API key、password、access tokenなどの認証情報が必要になります。
ここで避けたいのが、secretをHTTP header、Expression、Code、Sticky Noteへ直接書くことです。Workflowが動いても、画面共有、execution data、JSON export、Git管理などを通じてsecretが漏れる経路を増やしてしまいます。
Workflowの処理設定
＋
Credentialsに保存した認証情報
→ 実行時に組み合わせて外部サービスへ接続n8nのCredentialsは、認証情報をWorkflowの処理内容から分離し、安全に保存・再利用する仕組みです。
今日の到達点
- Credentialsとsecretの役割を説明できる
- API key、Bearer token、Basic Auth、OAuth2の違いを整理できる
- nodeへsecretを直書きしない理由を説明できる
- credentialの再利用、共有、移行時の注意点を理解できる
- Cloudとself-hosted、planによる管理方法の違いを把握できる
Credentialとsecretは同じではない
secretは、第三者に知られてはいけない値そのものです。
- API key
- password
- Bearer token
- OAuthのclient secret、access token、refresh token
- private key
credentialは、接続に必要な値と認証方式をn8n内でまとめた設定です。
たとえば「headerのどの名前でAPI keyを送るか」「OAuth2のauthorization URLやscopeは何か」といった構造も含みます。
n8n公式ドキュメントでは、Credentialsは外部APIやdatabaseへ接続するための認証情報として説明されています。保存されたcredentialsはdatabase内で暗号化され、通常のnode設定とは分離されます。
なぜnodeへ直書きしてはいけないのか
HTTP Request nodeのHeadersへ実際のtokenを固定値で入力しても、requestは送れます。しかし、secretがWorkflow定義の一部になります。
Authorization: Bearer <実際の値をここへ書かない>Workflow内の値は、次の場所へ現れる可能性があります。
- node設定画面やスクリーンショット
- コピーしたnode情報
- Workflow JSON
- Gitやバックアップ
- executionのINPUT／OUTPUT
- エラー表示やデバッグ用データ
- 記事、チャット、作業票
Credentialsを使えば、node側には「どのcredentialを使うか」という参照を持たせ、secret本体を処理設定から切り離せます。
ただし、Credentialsを使えば無条件に安全という意味ではありません。権限が広すぎるtoken、不要な共有、公開端末での管理などは別途対策が必要です。
主な認証方式
認証方式はn8nが自由に決めるものではありません。接続先APIの仕様に合わせます。
API key
API keyは、サービスが発行した文字列で利用者やapplicationを識別する方式です。送信場所はAPIによって異なります。
Header:
X-API-Key = <secret>Query:
api_key = <secret>query parameterはURLやアクセスログ、履歴などへ残る可能性があります。APIがheader方式を提供している場合は、通常はそちらを選びます。最終的には提供元ドキュメントの指定に従ってください。
Bearer token
Bearer tokenは、通常Authorization headerへ送ります。
Authorization: Bearer <token>n8nのHTTP Request credentialsにはBearer authがあり、tokenをcredentialへ保存できます。
Bearer tokenを持つ者は、そのtokenに許可された操作を実行できます。権限、scope、有効期限を必要最小限にすることが重要です。
Basic Auth
Basic Authはusernameとpasswordを使う方式です。HTTP RequestのGeneric Credential Typeでは、Basic auth credentialへ両方を保存します。
Basic Authのheader表現は暗号化ではありません。通信経路を保護するためHTTPSを使用し、可能なら個人用passwordではなく、連携専用accountや限定権限の値を使います。
OAuth2
OAuth2は、利用者のpasswordをn8nへ直接渡す代わりに、認可フローを通じてaccess tokenを取得する仕組みです。
Authorization Codeでは、利用者がサービス側で同意し、redirect URLを経由して認可を完了します。Client Credentialsは、利用者本人の代理ではなくapplication自身のresourceへアクセスする用途で使われます。
n8nのOAuth2 credentialでは、grant typeに応じて次のような情報を設定します。
- authorization URL
- access token URL
- client ID
- client secret
- scope
- redirect URL
必要な値やscopeは、接続先サービスの公式ドキュメントで確認します。
PredefinedとGeneric Credential Type
HTTP Request nodeでは、主に次の2種類を選べます。
| 種類 | 用途 |
|---|---|
| Predefined Credential Type | n8nが対応するサービス用credentialを利用する |
| Generic Credential Type | Basic、Header、Bearer、OAuth2などを自分で構成する |
n8n公式は、利用できる場合はPredefined Credential Typeを推奨しています。必要な項目が整理され、同じサービスの専用nodeで作ったcredentialをHTTP Requestでも利用できる場合があります。
専用typeがない場合はGenericを使用します。
「API keyだから必ずHeader Auth」と決めつけず、提供元が要求するheader名、prefix、query名、OAuth flowを確認してください。
credentialを作成してnodeから参照する
基本の流れは次のとおりです。
接続先の認証仕様を確認
→ credential typeを選ぶ
→ credential画面へsecretを入力して保存
→ nodeのAuthenticationでcredentialを選択
→ 接続をテストcredentialは画面上のCreateから作成できるほか、nodeのcredential選択欄からCreate Newを選んで作成できます。保存時には、対応するcredentialで接続テストが行われます。
名前はサービス、環境、用途が分かるようにします。
Example API - development - read onlycredential名を初期名のまま放置すると、数が増えたときに誤選択しやすくなります。
一方、credential名はWorkflow JSONに含まれるため、メールアドレス、顧客名、secretの一部などの機密情報を名前へ入れないようにします。
credentialの再利用とrotation
複数nodeから同じcredentialを選択すれば、secretを各nodeへ重複入力せずに再利用できます。
Credential A
├→ HTTP Request 1
├→ HTTP Request 2
└→ サービス専用nodeAPI keyを更新する場合も、各nodeのheaderを書き換えるのではなく、credentialを更新できます。この一元化が秘密情報を分離する大きな利点です。
一方、開発、検証、本番で同じcredentialを使い回すと、テスト操作が本番データへ影響する可能性があります。環境や用途ごとにcredentialと権限を分けます。
credentialを更新したときは、影響を受けるWorkflowを把握し、安全な範囲で接続を再確認します。
credentialの共有は権限付与である
対応planでは、credentialをほかの利用者やprojectへ共有できます。
共有された利用者はsecretの詳細を表示・編集できなくても、自分のWorkflowからそのcredentialを利用できる場合があります。
つまり、「値が見えない」と「権限がない」は同じではありません。
- credentialで実行できる操作
- 操作対象となるresource
- 共有相手
- project membership
- tokenに設定されたscope
これらを確認して共有します。
2026年9月時点の公式ドキュメントでは、credential sharingはn8n Cloudの全planと、self-hostedのBusiness／Enterpriseで利用できます。利用環境や権限によって表示される機能は異なります。
HTTP Requestでcredentialを使う場合、対応credentialにはAllowed HTTP Request Domainsを設定できます。Specific Domainsで送信先を限定すると、本来と異なるURLへcredentialを送る誤用を減らせます。
Workflowをexportするときの注意
n8nのWorkflow JSONにはcredential名とIDが含まれます。ID自体はsecretではありませんが、名前に顧客名やaccount情報が含まれていれば内部情報が公開されます。
さらに、cURLからHTTP Request nodeへ取り込んだ場合、認証headerがnode parameterへ含まれている可能性があります。
共有前には次を確認します。
- credential名を匿名化する必要がないか
- Headers、Query Parameters、Bodyにsecretがないか
- test dataやpinned dataにsecretがないか
- Sticky NoteやCodeにsecretがないか
- 実URL、account IDなどの非公開情報がないか
「credentialの入力欄が伏字だから、Workflow JSON全体も安全」とは判断しません。exportしたファイル自体を確認します。
Cloudとself-hostedの違い
n8nはcredentialsを暗号化してdatabaseへ保存します。
self-hostedでは、最初の起動時に生成されるencryption keyを使います。独自keyを環境変数N8N_ENCRYPTION_KEYで設定でき、queue modeではすべてのworkerへ同じkeyが必要です。
encryption keyを失うと保存済みcredentialsを復号できなくなる可能性があるため、安全な場所へ保管し、通常の設定ファイルや公開repositoryへ登録しません。
self-hostedでは、credential overwritesを環境変数またはfile-based configurationから渡す方法もあります。これはinstance運用者向けの設定であり、Workflow制作者がnodeへ環境変数を直接書く方法とは区別します。
External secretsは、次のような外部vaultをn8n Credentialsから参照する機能です。
- 1Password Connect Server
- AWS Secrets Manager
- Azure Key Vault
- GCP Secrets Manager
- HashiCorp Vault
- Infisical
2026年9月時点では、n8n Cloud Enterpriseとself-hosted Enterpriseで利用できます。
plan、n8n version、hosting形態によって利用できる機能が異なるため、「self-hostedならexternal secretsを必ず使える」とは限りません。
安全運用の最小ルール
- secretはnode parameter、Code、Sticky Noteへ直書きしない
- 実値を記事、チャット、Result、スクリーンショットへ残さない
- 利用可能ならPredefined Credential Typeを優先する
- tokenの権限、scope、有効期限を必要最小限にする
- 開発用と本番用のcredentialを分ける
- credential名にも機密情報を含めない
- 共有先とproject membershipを定期的に見直す
- 退職、漏えい、用途終了時はtokenを失効またはrotationする
- export共有前にJSONを確認する
- HTTPSやcertificate検証を安易に無効化しない
今日の実習で確認すること
- Credentialsの作成場所を確認する
- nodeのAuthenticationからcredentialを選ぶ流れを確認する
- PredefinedとGeneric Credential Typeの違いを見る
- API key、Basic Auth、OAuth2で表示される設定項目を比較する
- Workflow JSONにcredential名とIDが含まれることを確認する
- node parameterにsecret本体がないことを確認する
- 自分用の「secret直書き禁止」ルールを記録する
実secret値は、実習画面の共有、スクリーンショット、Resultへ残しません。
まとめ
Credentialsは、secretをWorkflowの処理定義から分離し、暗号化して保存・再利用するための仕組みです。
APIの認証仕様を確認
→ 適切なcredential typeを選ぶ
→ secretをcredentialへ保存
→ nodeはcredentialを参照
→ 共有・export・rotationまで管理する重要なのは「接続できたか」だけではありません。
誰がそのcredentialを使えるか、どのresourceへ何ができるか、どこへsecretが残り得るかまで含めて設計することで、Workflowを継続的に安全運用できます。
