Google Auth Platform の基礎

Google OAuth 2.0 クライアント ID / シークレットの役割整理

AWS Application Load Balancer（ALB）における OIDC 認証 と、一般的な SaaS 等における Google API（Google Ads API 等）連携 の関係および違いをわかりやすくまとめたドキュメントです。

1. 結論（全体の要約）

クライアント ID / シークレットは共通で必要
- どちらの用途でも、Google に対して「どのアプリケーションからのアクセスか」を証明するために、Google Cloud で発行した OAuth 2.0 クライアント ID とクライアントシークレットを使用します。
目的と仕組みが異なる
- ALB（OIDC）: ユーザーの本人確認（ログイン制御）のために使用。
- SaaS 連携（OAuth 2.0）: ユーザーの代わりに Google API を操作する（データ取得・更新） ために使用。

2. 用途別の比較一覧

比較項目	① AWS ALB の OIDC 認証	② SaaS 等の Google API 連携
主な目的	ユーザーの認証（ログイン制限）	認可（データアクセス権限の委譲）
対象データ	ユーザーのプロフィール情報（名前・メール）	ユーザーが保有する Google サービス内のデータ（例: Google 広告の配信データ）
主に使用するプロトコル	OpenID Connect (OIDC) (認証用)	OAuth 2.0 (認可用)
中心となるトークン	ID トークン (JWT)	アクセストークン / リフレッシュトークン
クレデンシャルの設定箇所	AWS ALB のリスナールール設定	SaaS アプリのバックエンド（環境変数や DB）
トークンの保持・管理主体	ALB / ブラウザのセッション	SaaS アプリのバックエンド DB

3. 各パターンの処理フロー

A. ALB の OIDC 認証（アプリへのログイン制御）

[ユーザー] ──① アクセス ──> [AWS ALB] ──(未認証ならリダイレクト)──> [Google ログイン]
    │                                                                   │
    │<───③ ID トークン発行 ─────────────────────────────────────────────┘
    │
    └───④ ID トークンを提示 ──> [AWS ALB] ──(検証OKなら通過)──> [バックエンド Web アプリ]

役割: ALB がドアマンとして機能し、認証されたユーザーのみを奥の Web アプリに通します。
ポイント: ユーザーの Google データ（Google 広告等）を操作する権限は保持しません。

B. SaaS の OAuth 連携（Google サービスのデータ連携）

[ユーザー] ──① 連携承認 ──> [Google ログイン]
    │                             │
    │<──② 認可コード返却─────────┘
    │
    └──③ 認可コード送信 ──> [SaaS サーバー] ──④ トークン交換 ──> [Google]
                                  │
                                  └──⑤ アクセス/リフレッシュトークンを DB 保存
                                       (バックグラウンドで Google Ads API 等を実行)

役割: ユーザーから許可をもらい、SaaS サーバーが裏側で定期的に Google API を呼び出します。
ポイント: SaaS 側がリフレッシュトークンを暗号化して保存・管理する必要があります。

4. セキュリティ上のベストプラクティス

同一の「クライアント ID / シークレット」を ALB 認証と API 連携で使い回すことも技術的には可能ですが、運用環境では個別に作成・分離することが推奨されます。

認可リダイレクト URI の分離
- ALB 用: https://<ALBのドメイン>/oauth2/idpresponse
- API 用: https://<アプリのドメイン>/api/auth/callback
権限の最小化とリスク局所化
- 万が一どちらかのシークレットが漏洩した場合でも、もう一方のシステムに影響を与えずに個別に再発行・無効化が可能です。