n8nとGoogleサービスの連携

n8nを使ってGoogle スプレッドシートを操作するワークフローを作成した際に、Googleへの認証方法について戸惑ったので、そのことを今回は記事にまとめたいと思います。

記事のポイント

n8nとGoogleサービスにおける認証の設定方法
n8nとGoogleサービスにおける認証方法のメリット・デメリット
n8nとGoogleサービスにおける認証方法の選択基準

n8nとは？
なぜ認証が必要なのか？
この記事で言いたいこと
n8nのGoogleサービスへの認証方法
OAuth とサービスアカウントの比較と使い分け
- 比較表
  - OAuth 2.0を選ぶべき場合:
  - サービスアカウントを選ぶべき場合
まとめ

n8nとは？

この記事から読み始めた方のために、簡単にn8nをご紹介します。 n8nは、拡張可能なワークフロー自動化ツールです。ソースコードが公開されており、セルフホストが可能で、独自のカスタム関数、ロジック、アプリを追加できます。n8nのノードベースのアプローチは非常に汎用性が高く、あらゆるものを接続できます。例えば、Gmail、Google Sheets、Google カレンダーなどの Google サービスや、Notion、Generative AIなどとの連携によってタスクの自動化が可能なツールです。

なぜ認証が必要なのか？

n8nで Google スプレッドシートを操作しようとすると、まず認証情報の設定が必要になります。具体的には、以下の画面です。

これは n8n が Google スプレッドシートにアクセスし、データを読み書きするために、Google 側から「この n8n インスタンスはあなたの Google アカウントにアクセスすることを許可されている」という明確な「承認」を得る行為です。データ保護の観点から、誰が、どのように、どのデータにアクセスしているかを管理することは常識となっています。認証がなければ、n8n は許可なく勝手に Google スプレッドシートにアクセスできてしまい、セキュリティ上の大きな問題となるため、認証は必須です。

この記事で言いたいこと

セルフホステッド環境の n8n で Google スプレッドシートを安全に操作するための主要な2つの認証方法、「OAuth 2.0」と「サービスアカウント」について解説します。それぞれの認証方法の違いや、実用上のメリット・デメリット、どのような状況でどちらを選ぶべきかをお伝えします。

n8nのGoogleサービスへの認証方法

n8n で Google Sheets ノードを含む Google サービスノードを利用する際、主に「OAuth 2.0」と「サービスアカウント」という二つの認証方法が提供されています。これらはそれぞれ異なる目的と特性を持っています。

OAuth2.0

OAuth 2.0 は、n8n のようなアプリケーションがユーザーの Google アカウントの代理として Google リソースにアクセスするための標準的な認可フレームワークです。ユーザーがログイン情報を直接 n8n に渡すことなく、Google が発行するアクセストークンを使ってアクセスを許可します。これは、家の鍵を渡さずに一時的な入館証を発行するような仕組みです。OAuth 2.0 により、アプリはユーザーの保護されたリソースに限定的にアクセスでき、ユーザーはログイン情報を提供せずに済みます。

メリット

OAuth 2.0 を使う際のメリットは以下の通りです。

セキュリティが高い
ユーザーにとってわかりやすい認証フロー
権限の細かな制御が可能

OAuthを使う場合、ユーザは自身のアカウントを使い、普段Googleにログインするような形で認証を行うことができます。また、その際、n8nにGoogleの認証情報（ユーザ情報やパスワード）を渡すわけではないので、情報漏洩の観点からもリスクが低減されます。また、OAuthスコープと呼ばれる、認可時の権限を定義し、その定義に応じてユーザの操作を決定付ける事が可能となります。

デメリット

OAuth 2.0 を使う際のデメリットは以下の通りです。

未検証アプリではリフレッシュトークンの有効期限が7日と短い
セルフホステッドでは公開ドメインかトンネルサービスが必要

特に注意が必要なのは、未検証アプリの場合、アクセストークンを自動的に再取得するための「リフレッシュトークン」が7日で期限切れになる点です。これは、Google Cloud Consoleで作成されたOAuthアプリケーションが「テストモード」のままであり、Googleによる公式な「検証」を受けていないことが原因です。この未検証状態が続くことで、リフレッシュトークンの寿命が短く制限され、結果として7日ごとに手動で再認証を行う必要が生じてしまうため、処理自体を自動化しても、再認証の必要性によって認証エラーとなり手動での対処が必要となります。 OAuthの認証には、n8nを立てる環境に対して公開ドメインを取得する、もしくは、トンネルサービスが必要となります。これはOAuthの仕組み上の制約ですが、OAuthは認証を行うと、トークンと呼ばれる認可コードを返します。その際、リクエストURIにコードを返すわけですが、これは外部からアクセスできるURIでないと、返すことができません。そのため、localhostのようなローカルアドレスは使えず、セルフホステッドn8nがOAuthを利用するには、公開ドメインまたは一時的なトンネルサービス（例: ngrok）が必要になります。

推奨される用途

業務ユーザー向けや小規模な個人利用など、ユーザーアカウントに紐づくアクセスを行う場合に適しています。

OAuth2.0とn8nの設定方法

OAuth 2.0 の設定は、Google Cloud Console と n8n の両方で行います。

前提条件

Googleアカウントを所有していること。
セルフホステッド n8n インスタンスが外部からアクセス可能なドメインを持っていること
ドメインがない場合はテスト用に ngrok などのトンネルサービスの使用も可能（本番環境には非推奨）

Google Cloud Console プロジェクトの作成

プロジェクトとは、Google Cloud上でAPIやサービスを管理するための「入れ物」のようなものです。このプロジェクト内で、n8nがGoogleサービスにアクセスするための設定を行います。

・　 Google Cloud Console (console.cloud.google.com) にアクセスします。

・　画面上部のプロジェクト選択ドロップダウンメニューから「新しいプロジェクト」を選択します。

・　プロジェクト名（例: n8n-sheets-project）を入力し、必要であれば組織を選択して「作成」をクリックします

必要なAPIの有効化(今回はGoogle SpreadSheetsを例にします。)

n8nがGoogleスプレッドシートを操作するためには、Googleに対してそのAPI（プログラムからGoogleスプレッドシートを操作するための窓口）の利用許可を明示的に与える必要があります。

・　作成したプロジェクトが選択されていることを確認します。

・　左側のナビゲーションメニューから「APIとサービス」>「ライブラリ」へ移動します。

・　検索バーで「Google Sheets API」と入力し、検索結果から「Google Sheets API」を選択します。

・　「有効にする」ボタンをクリックして、このAPIをプロジェクトで利用できるようにします。

・　有効にすると以下の画面に遷移します。

・　同様に「Google Drive API」も有効にします。

OAuth 同意画面の設定

・　左側のナビゲーションメニューから「APIとサービス」>「OAuth同意画面」へ移動します。

・　「開始(Get started)」を選択し、設定を開始します。

・　アプリ情報に必要な情報を入力し、次へを押下します。

アプリ名: n8nのインスタンス名など、ユーザーが認証時に表示される分かりやすい名前を入力します

ユーザーサポートメール: あなた自身のメールアドレスを入力します。

・　対象情報で内部/外部のいずれかを選択し、次へを押下します。

通常は「外部」を選択します。（これにより、Googleアカウントを持つすべてのユーザーがアプリを利用できるようになります。あなたのGoogleアカウントも含まれます。）Google Workspace組織内のユーザーのみに限定する場合は「内部」を選択します。

・　連絡先情報で連絡先を入力し、次へを押下します。

・　終了情報でポリシー同意にチェックをいれて、作成を押下します。

承認済ドメインの設定

OAuthフローが完了した後にGoogleが認証情報をn8nに安全にリダイレクトするために不可欠な設定です。

・　左側のメニューから「ブランディング」を押下し、承認済ドメインの「+ドメインの追加を押下します」を押下し、ドメインを追加します。残念ながら、私の環境はlocalhostのため以下のようにエラーになりますが、公開ドメインであれば、設定できるはずです。

対象の設定

アプリが未検証（公開ステータスがテスト中）の状態でも、あなたがテストユーザーとしてアクセスを許可できるように設定をします。

・　左側のメニューから「対象」を押下し、テストユーザーの　「+ Add users」を押下します。

・　 Googleアカウントのメールアドレスを追加し、保存します。

OAuth クライアントIDの作成

ここで最後に生成される「クライアントID」と「クライアントシークレット」が、n8nとGoogleを安全に紐づけるための「鍵」となります。これらは外部に漏洩しないよう注意してください。また、発行したシークレット情報はJSONダウンロードをし、厳重に保管するようにしてください。

・　左側のメニューから「クライアント」を押下し、OAuth2.0 クライアントID画面に遷移します。

・　上部の「クライアントを作成」を押下し、OAuth2.0のクライアントを作成します。

・　アプリケーションの種類: 「ウェブアプリケーション」を選択します。

・　名前: 任意の分かりやすい名前を入力します

・　承認済みのリダイレクトURI：n8nの「認証情報」セクションで認証方法として「OAuth2」を選択すると、「OAuth Redirect URL」というURLが表示されます。このURLをコピーし、 Google Cloud Consoleの「承認済みのリダイレクトURI」フィールドにペーストします。

・　作成ボタンを押下すると、以下のようにOAuthクライアントIDが発行されます。

n8nでの認証情報設定

ここからは、n8nの画面に戻って、Googleにアクセスするための設定を行い、認証プロセスが完了させます。

・　 Google Cloud Consoleで表示された「OAuth クライアントが作成されました」というダイアログから、「クライアントID」と「クライアントシークレット」をコピーします。もしくは、JSON内に記載されている「クライアントID」と「クライアントシークレット」の内容をコピーします。

・　n8nの「認証情報」セクションに戻り、新しいGoogle認証情報の追加画面で、コピーしたクライアントIDとクライアントシークレットをそれぞれのフィールドにペーストします　

・　「Sign in with Google」ボタンをクリックします。

・　Googleの認証画面にリダイレクトされ、あなたのGoogleアカウントでログインし、n8nへのアクセスを許可するよう求められます。

・　認証が完了すると、n8nの画面に戻り、認証情報が保存されます。今回私の場合は、n8nをlocalhostで動かしているため、以下の画面のようにlocalhostでの接続拒否がされます。

注意点

今回、私の環境下では、公開ドメインを持たないため、OAuth2.0のトークン受取ができず、失敗しましたが、本来はこの手順で設定ができるはずです。ただし、設定ができても、注意点はあります。未検証の状態では、前述の通りリフレッシュトークンが7日で期限切れになるため、定期的な再認証が必要になることを忘れないでください。長期的な無人運用でこれを避けたい場合は、Googleのアプリ検証プロセスを完了する必要があります

サービスアカウント

サービスアカウントは、n8nのようなアプリケーションや、サーバー上のワークロードが、人間を介さずにGoogleサービスにアクセスするために設計された特別な種類のGoogleアカウントです。通常のユーザーアカウントとは異なり、特定の個人に紐づくものではなく、独自のメールアドレスによって識別されます。これらのアカウントは、GoogleのIAM (Identity and Access Management) サービスによって管理され、特定のGoogleリソースへのアクセス権限を付与することができます。例えるなら、特定のタスクを自動で実行するために、Googleが発行した「ロボット用のIDカード」のようなものです。サービスアカウントは、そのメールアドレスによって識別され、プリンシパル（サービスアカウント）とそのサービスアカウントに関連付けられたプロジェクトを識別します。

メリット

サービスアカウントを使う際のメリットは以下です。

トークンの有効期限を意識せずに済む
ユーザーアカウントに依存しない

OAuthのように7日問題のようにリフレッシュトークンの期限切れを心配する必要がありません。一度設定すれば、キーファイルが有効な限り永続的に動作します。また、ユーザアカウントに紐づかないため、企業における人の退職やアカウントの変更に影響されることがありません。