最初から失敗ならエラー文字列、約7日後ならAudienceと
初回認証で redirect_uri_mismatch： n8n表示のRedirect URLを、同じGoogle OAuth clientへ完全コピー。一度成功後、約7日で再認証： External／Testing／scope（要求する権限）／同意日を確認。
URL不一致、対象ユーザー、7日失効を同じ原因にしません。
- N8NOAuth Redirect URL表示値をコピー→
- GOOGLEAuthorized redirect URIs同じClientへ完全一致で登録→
- CONSENTAudience / Test users使うGoogleアカウントを通す→
- RETURNn8nへcallback（認証後の戻り先）再接続後に1件だけ読む
図はCustom OAuth2の往復を簡略化したものです。Client Secret、認可コード、refresh tokenは記事やスクリーンショットへ載せません。Client IDは秘密値ではありませんが、公開画像では設定の対応付けを避けるため伏せます。
エラー名より先に、「いつ止まったか」を分けます。
接続ボタンを押してすぐ止まるなら、Redirect URL、Client ID、対象ユーザーを確認します。一度使えたのに約7日で切れたなら、External・Testingの期限が候補です。
URL・Client・Test user
redirect_uri_mismatch、access_denied、invalid_clientを区別します。
Testing・scope・同意日
Googleへの認可と、access tokenを更新するrefresh tokenの失効条件を確認します。
Google Sheetsのnode（ノード）で403になる場合は、OAuth接続そのものではなく、必要なAPI、scope、対象ファイルの共有権限かもしれません。CustomではSheets APIに加えDrive APIも確認します。接続後の403診断と読み取り例へ進んでください。
n8n Cloudなら、Google Cloud Consoleを開く前に接続方式を確認します。
n8n公式資料では、対応するGoogle nodeをn8n Cloudで使う場合、Credential（認証情報）画面からManaged OAuth2の「Sign in with Google」が利用できます。この方式ならGoogle Cloud ConsoleでのCustom設定は不要です。
Credential画面の「Sign in with Google」から接続します。対応nodeかを公式一覧で確認します。
認証方式をCustomへ切り替えた場合は、自分のGoogle Cloud project、Client、Redirect URLを管理します。
Managed OAuth2は使えません。Google CloudでAPI、Audience、OAuth clientを設定します。
いいえ Custom OAuth2
はい 対応nodeでManagedの接続ボタンがあるならManaged。なければCustom
古い記事にはCloudでも必ずGoogle projectを作る手順があります。今見えているCredential画面と、対象nodeの現行公式一覧を優先してください。
エラー文字列と発生段階を、同じ行で読みます。
| 表示・症状 | 止まった段階 | 最初の確認 |
|---|---|---|
redirect_uri_mismatch | Googleへ移動した直後 | n8n表示URLとAuthorized redirect URIsを完全一致 |
access_denied | 同意画面の前後 | Test user登録、利用者の拒否、組織ポリシーを確認 |
Google hasn't verified this app | 同意画面 | 警告であり接続失敗とは限らない。scopeとverification状態を確認 |
invalid_client | 接続開始時 | 同じOAuth clientのClient ID／保存済みSecretとの対応を確認 |
約7日後に再認証 | 一度成功した後 | External・Testing、要求scope、同意日を確認 |
node実行時の403 | 接続後のworkflow | CustomのSheetsはSheets API＋Drive API。scopeと共有権限も別に確認 |
invalid_grantは、無効な認可コードや、期限切れ・無効化されたrefresh tokenでも起きます。7日失効と決めつけず、発生時点とPublishing statusを記録して、必要ならCredentialから再接続します。
redirect_uri_mismatchは、n8nの表示値をGoogleへ完全コピーします。
Googleは、認証要求に含まれるredirect_uriが、同じOAuth clientへ登録したAuthorized redirect URIsの1つと一致しないと、このエラーを返します。
https://n8n.example.com/rest/oauth2-credential/callback一致http://n8n.example.com:5678/rest/oauth2-credential/callbackscheme・porthttps://n8n.example.com/rest/oauth2-credential/callback/末尾 /大小文字、scheme、port、path、末尾スラッシュまで、n8n画面の値と同じ文字列にします。推測で直さず、そのままコピーします。
- 01n8nのCredentialを開く
OAuth Redirect URLを画面からコピーします。記事の例URLを自分のURLとして使いません。
- 02Google Auth PlatformのClientsを開く
n8nへ入力したClient IDと同じOAuth clientを選びます。
- 03Authorized redirect URIsへ貼る
Authorized JavaScript originsではありません。scheme、host、port、path、末尾スラッシュまで照合します。
- 04保存後にn8nから再接続する
設定の反映待ちを考慮し、保存時刻を残します。同じエラーなら、別のOAuth clientを編集していないかを再確認します。
self-hostedの運用環境で、意図せずlocalhostや内部portが出るなら、表示元を先に直します。
ローカル開発ではhttp://localhost:5678/rest/oauth2-credential/callbackを使えます。localhost以外の運用環境では、利用者のブラウザから到達できるHTTPSのhostと正しいcallback pathが必要です。
n8n画面のOAuth Redirect URLへ内部portや誤ったhostが出るなら、Google側だけを合わせず、公開URL設定を直してから表示値を登録します。
Credential画面のOAuth Redirect URLが意図したURLと違う場合は、Editorの公開URLを指定するN8N_EDITOR_BASE_URLを導入環境の設定で確認します。Webhook用URLとは役割を分けて扱い、最後はCredential画面の表示値を照合します。
reverse proxy（リバースプロキシ）がある場合は、N8N_PROXY_HOPSとX-Forwarded-For、X-Forwarded-Host、X-Forwarded-Protoも確認します。n8n公式がWebhook用に案内する現行名はN8N_WEBHOOK_URLで、旧WEBHOOK_URLは2.35.0以降非推奨です。
Google側を内部URLに合わせて回避せず、利用するブラウザから到達できるEditor URLへ揃えます。
一度つながって7日後に切れるなら、External・Testingを確認します。
Google公式では、Audience（利用対象）がExternal、Publishing status（公開ステータス）がTestingのアプリで、テストユーザーの認可は同意から7日で失効します。offline accessで得たrefresh tokenも失効します。
一度接続できたのに再認証を求められる場合、この条件を確認します。
openid、基本プロフィール、メールだけを求める場合は例外です。Sheets、Drive、Gmail等の追加scopeでは同じ例外になりません。
- Audience
- Internal / External
誰が使えるアプリか。Internalはprojectが属するGoogle Cloud Organizationのメンバーに限定します。Externalは組織外のGoogleアカウントも対象です。
- Publishing status
- Testing / In production
Externalアプリの公開状態。Testingは開発用、In productionは継続利用側の状態です。
- Test users
- Testingで認可できるアカウント
External・Testingでは、ここへ追加したGoogleアカウントだけが通常のOAuth flowを完了できます。
- Verification
- Googleによるscope・表示等の確認
Publishing statusとは別です。In productionへ移しても、要求scopeと利用方法により必要になります。
Test usersへの追加は認証を許可する設定で、7日失効は止めません。開発中は必要に応じてn8n Credentialから再接続し、継続運用ではIn productionへの移行とverificationの要否を確認します。
個人検証と第三者向けサービスを同じ運用にせず、必要なscopeだけを選びます。
該当した原因だけを直し、必要な場合だけ再接続します。
- 01接続方式を固定する
n8n CloudのManagedか、自分で設定するCustomかを途中で混ぜません。
- 02エラー表で該当した1か所を直す
URI不一致、対象ユーザー、7日失効、API・scopeのうち、表示された症状に対応する設定だけを変更します。
- 03環境変数を変えた場合だけ再起動する
再起動後、Credential画面のRedirect URLが意図した値へ変わったか確認します。
- 04必要なら再接続し、1件読む
OAuth設定を変えた場合はCredentialを再接続します。API有効化や共有権限だけを直した場合は、そのままnodeを再実行します。
接続後の403は、API・scope・ファイル権限を分けて確認します。
Custom OAuth2でGoogle Sheetsを使うなら、Sheets APIとDrive APIの両方が必要です。n8n公式の前提では、DocsとSlidesも、それぞれのAPIに加えてDrive APIが必要とされています。
Google Cloud Console上部でOAuth clientと同じprojectを選び、「APIs & Services → Library」から不足したAPIを有効化します。「Enabled APIs & services」で両方を確認してください。Managed利用者がこのためにCustomへ切り替える必要はありません。
- APIサービスを利用できるか
Custom：同じprojectで
Sheets API ＋ Drive API - scopeアプリに何を許可したか
必要な読み取り権限が
認可に含まれるか - ファイル共有誰がそのSheetを読めるか
接続したGoogleアカウントで
対象ファイルを開けるか
3つは別の確認です。APIの有効化は、ファイルを一般公開する設定ではありません。権限を一括で広げず、エラー本文が示す箇所から確認します。
scope不足を示す場合は、使うGoogle Sheets credentialと認可内容を確認して再接続します。共有権限が原因なら、所有者にそのGoogleアカウントの閲覧権限を依頼します。組織によるブロックは管理者へ確認し、制限を回避しません。
練習例：ブログの確認メモを1行だけ読む
ここからは公式のGet Row(s)操作を基にした練習案です。接続済みのGoogle Sheets credentialと、同じアカウントで編集できるテスト用スプレッドシートを用意します。実際の接続結果ではなく、下の出力は期待値です。
- 01テスト用Sheetを用意する
新しいスプレッドシートを「OAuth確認用」、シートのタブ名を「接続テスト」にします。A1を
check_id、B1をnote、A2をoauth-read-01、B2を接続確認にし、ほかのデータは入れません。 - 02手動実行から読み取りnodeへつなぐ
n8nで新しいworkflowを開き、Manual Trigger → Google Sheetsを接続します。Credentialには確認したものを選び、Resourceを「Sheet Within Document」、Operationを「Get Row(s)」にします。Append・Update・Deleteは使いません。
- 03読むファイルとタブを指定する
Documentを「By URL」にし、いま作ったスプレッドシートのURLを貼ります。Sheetは「By Name」で
接続テスト。Filtersは空欄、ほかは初期値で、1行目を見出しとして読みます。 - 04手動実行し、出力の2項目を照合する
「Execute workflow」で実行し、Google Sheets nodeのOutputを開きます。1 itemが返り、
check_idとnoteが下の期待値に一致すれば、このファイルの読み取り確認は完了です。定期実行の公開・有効化は不要です。
{
"check_id": "oauth-read-01",
"note": "接続確認"
}0件ならURL・タブ名・A2/B2の値・Filters・データ範囲を確認します。403なら上の3層へ戻り、エラーに書かれたAPI名や権限を照合します。invalid_grantなら認可期限を確認してCredentialを再接続し、同じ1行を再読します。
この成功は、テスト用ファイルをその時点で読めた証拠です。7日後の継続接続や、別ファイルへの書き込みまで確認できたことにはなりません。
問い合わせるなら、秘密を除いた1枚の診断メモを作ります。
Client Secret、refresh token、認可コード、Cookieを送らなくても、接続方式、エラー段階、Redirect URLの差、Audience、Publishing statusは共有できます。Client IDは秘密値ではありませんが、公開メモでは末尾4文字だけでClientを区別できます。
確認日時（タイムゾーン）:
n8nの版:
n8n Cloud / self-hosted:
Managed OAuth2 / Custom OAuth2:
エラー文字列:
失敗した段階: 接続前 / 同意画面 / callback / 接続から約7日後 / node実行時
n8n表示のOAuth Redirect URL:
Google登録のAuthorized redirect URI:
scheme・host・port・path・末尾スラッシュの差:
Audience: Internal / External
Publishing status: Testing / In production
対象アカウントをTest usersへ追加: はい / いいえ / 対象外
OAuth clientとAPIを設定したGoogle Cloud projectが同じ: はい / いいえ / Managedのため対象外
有効化したGoogle API（CustomのSheetsはSheets APIとDrive API）:
接続したGoogleアカウントで対象ファイルを開ける: はい / いいえ
要求scope（秘密ではないが必要最小限だけ記録）:
保存・再起動・再接続を行った時刻:
次に確認する1点:n8nとGoogle OAuthで、最後に迷いやすいこと
n8n CloudでもGoogle Cloud projectは必要ですか？
対応Google nodeのManaged OAuth2なら不要です。Credential画面でCustomへ切り替えた場合や、非対応node、self-hostedではCustom設定が必要です。
Testingのままでも使えますか？
登録したTest userは使えます。ただし追加のGoogle API scopeを使うExternal・Testingの認可とrefresh tokenは同意から7日で失効します。
In productionにすればverificationは不要ですか？
一律ではありません。要求scopeや利用者によって、検証、未確認アプリ警告、ユーザー上限が関係します。Google Auth Platformに表示される条件を確認します。
設定を直したのに同じエラーが続くのはなぜですか？
設定の反映待ちや、別project・別OAuth clientを編集した可能性があります。保存時刻とClient IDの対応を確認し、同じエラーの発生段階をもう一度照合してください。Secretは安全に保存した値を使い、公開メモへ貼りません。
Sheets APIを有効にしたのに403になるのはなぜですか？
Customでは同じprojectのDrive APIも確認します。APIが揃っていれば、scope、接続アカウントのファイル共有権限、組織ポリシーを別々に照合します。Managedでは自分のGoogle projectを新設する必要はありません。
最初から失敗と、7日後の失効を混ぜない。
redirect_uri_mismatchなら、n8n画面のOAuth Redirect URLとGoogle側のAuthorized redirect URIsを完全一致させます。self-hostedで表示URLが誤っている場合は、Google側ではなく公開URL設定から直します。
一度つながって約7日後に切れたら、External・Testing、Test users、要求scope、同意日を確認します。最後にテスト用データを1件だけ読み、Credentialとnode実行の両方を確認してください。
確認した一次資料と、今回試していないこと
Managed／Custom、Redirect URL、External・Testingの7日失効と例外、必要API、Get Row(s)、EditorとWebhookの外部URL設定を公式資料で再確認しました。
当研究所ではGoogle Cloud project作成、API有効化、OAuth client作成、Test user追加、Production移行、n8n再起動、実アカウント接続を行っていません。画面名は公式資料を基にし、個別環境での成功を実測した記事ではありません。
接続できたら、workflowをバックアップする
設定を増やす前に、workflowの書き出しと、秘密を含めずに保管する方法を確認します。
AIを9/5の競合本文5件の比較、n8n・Google一次資料の再確認、構成、推敲、図解、実装と独立したAI読者による確認に使用しています。検索順位・検索量は未測定です。実アカウントでのOAuth接続は未検証で、広告・アフィリエイトリンクは設置していません。