developersIO
IAPにおけるOAuth同意画面の役割を整理してCloud Run + IAPで組織外ユーザーアクセスを試してみた

IAPにおけるOAuth同意画面の役割を整理してCloud Run + IAPで組織外ユーザーアクセスを試してみた

Google Cloud (GCP)OAuth 2.0Cloud Run
FacebookHatena blogX
2026.03.24

はじめに

こんにちは。
クラウド事業本部コンサルティング部の渡邉です。

Identity-Aware Proxy（IAP）を設定する際に、OAuth同意画面の構成を求められることがあります。

OAuth同意画面の構成を設定するにあたり、「内部と外部の違いは？」「公開ステータスがテスト中のままだとどうなるのか？」など、OAuth同意画面の設定は意外と混乱しやすいポイントが多い印象があります。（少なくとも私は混乱しました。）

本記事では、IAPにおけるOAuth同意画面の役割を整理し、Cloud Run + IAPで組織外のユーザーにアクセスを許可するハンズオンを通して、OAuth同意画面の作成を実際に試してみます。

認証と認可の違い

まず、基本中の基本である認証(Authentication) と 認可(Authorization) の違いを押さえておきましょう。

概念 英語 意味 身近な例
認証 Authentication 「あなたは誰ですか？」を確認すること 社員証を見せて本人確認する
認可 Authorization 「あなたは何をしていいですか？」を確認すること 入館証で入れる部屋が決まっている

IAPではOAuth同意画面が「認可」ではなく「認証」の目的で使われます。この違いが混乱の原因になりやすいため、後のセクションで詳しく解説します。

OAuth 2.0とGoogle CloudのOAuth同意画面の関係

IAPの仕組みを理解するために、まずOAuth 2.0とOAuth同意画面の関係を整理しておきます。

OAuth 2.0は、ユーザーのデータへのアクセス権をアプリケーションに委譲するためのプロトコルで、RFC 6749で定義されています。Google Cloudに限らず、GitHub、Microsoftなど多くのサービスで採用されている業界標準の仕組みです。

一方、Google CloudのOAuth同意画面は、このOAuth 2.0の仕組みを利用してユーザーに表示されるGoogle固有のUIです。Google Cloudのプロジェクト単位で構成します。

概念 位置づけ 説明
OAuth 2.0 プロトコル（RFC 6749） アクセス権の委譲を実現するための標準仕様
Google CloudのOAuth同意画面 Googleによる実装 OAuth 2.0の仕組みを利用してユーザーに表示されるGoogle固有のUI。プロジェクト単位で構成する

一般的なOAuth 2.0フローでは、アプリケーションがGoogle APIへのアクセス許可をユーザーに求める「認可」の画面としてOAuth同意画面が表示されます。しかし、IAPではこの仕組みを ユーザーの身元確認（認証） の目的で利用しています。IAPにおける具体的なフローは後述の「Identity-Aware Proxy(IAP) におけるOAuth同意画面」セクションで解説します。

OAuth同意画面とは

OAuth同意画面（OAuth Consent Screen）とは、OAuth 2.0フローの中でユーザーに表示されるGoogleのUIです。一般的なOAuth認可フローでは「データへのアクセス許可」を求める画面ですが、IAPでは「Googleアカウントでのログイン（身元確認）」を行う画面として機能します。

OAuth同意画面は、Google Cloudコンソールの Google Auth platform でプロジェクト単位に設定します。

ユーザーの種類：内部（Internal） vs 外部（External）

OAuth同意画面を構成する際に、最初に選択するのがユーザーの種類です。

項目 内部（Internal） 外部（External）
対象ユーザー 同じGoogle Workspace組織内のユーザーのみ Googleアカウントを持つすべてのユーザー
組織の要件 Google Workspace / Cloud Identityが必要 不要
Googleによる審査 不要 Sensitive / Restricted スコープ使用時に必要
テストユーザーの制限 なし（組織内全ユーザーが利用可能） テスト状態では登録したテストユーザーのみ
主な用途 社内ツール、社内ダッシュボード 一般公開アプリ、外部ユーザー向けサービス

社内利用のみであれば内部を選択します。Googleによる審査が不要で、Sensitive / Restricted などのスコープを使用しても追加のレビューは発生しません。一方、組織外のユーザーにもアクセスを許可する場合は外部を選択します。ただし、テスト段階では登録したテストユーザーしかアクセスすることができません。

迷った場合は、以下のフローチャートを参考にしてください。

公開ステータス：テスト中 vs 本番

Externalのユーザータイプを選択した場合、OAuth同意画面には公開ステータスがあります。

ステータス 説明
テスト中 テストユーザーとして登録されたGoogleアカウントのみがアクセス可能。リフレッシュトークンは7日で失効する（openid, email, profile スコープのみの場合を除く）
本番 Googleアカウントを持つすべてのユーザーがアクセス可能。Sensitive / Restricted スコープを使用する場合はGoogleによる審査が必要

よくあるハマりポイントとして、「外部で作成してテスト中の状態のまま忘れていた」というケースがあります。この場合、テストユーザーに登録されていないユーザーがアクセスしようとすると「アクセスがブロックされました」というエラー画面が表示されます。本番公開時には必ずIn productionに変更するか、Internalに切り替えることを忘れないようにしましょう。

スコープについて

OAuthスコープは、アプリがアクセスしたいデータの範囲を指定する文字列です。Google Workspace APIの利用など、OAuth認可フローではスコープの設定が重要になりますが、IAPの場合はユーザーの身元確認（認証）が目的であるため、スコープの設定は基本的に不要です。

なお、Externalを選択した場合、使用するスコープの機密性（Non-sensitive / Sensitive / Restricted）に応じてGoogleによる審査が必要になる場合があります。IAPのみの利用であればスコープを追加する必要がないため、この審査は通常発生しません。

OAuthクライアントIDのアプリケーションタイプ

OAuthクライアントIDを作成する際に、アプリケーションの種類を選択する必要があります。IAPで使用する場合はウェブアプリケーションを選択します。

IAPのOAuthクライアントIDでは、認証済みのリダイレクトURIにIAPのコールバックURLを設定する必要があります。具体的な設定手順はハンズオンのセクションで解説します。

Google Auth platform

Google Cloudコンソールでは、OAuth同意画面の設定UIがGoogle Auth platformに移行しています。従来の「APIとサービス > OAuth同意画面」から、以下の3つのセクションに分かれました。

セクション パス 設定内容
Branding Google Auth platform > Branding アプリ名、ユーザーサポートメール、ロゴ、ホームページURL
Audience Google Auth platform > Audience ユーザータイプ（Internal/External）、テストユーザー
Data Access Google Auth platform > Data Access スコープの追加・削除

OAuthクライアントIDの作成は、Google Auth platform > Clients から行います。

Identity-Aware Proxy(IAP) におけるOAuth同意画面

OAuth 2.0は本来「認可」のためのフレームワークですが、IAPでは認証として利用されます。

利用シーン OAuth同意画面の目的
Google Workspace API等 認可（Authorization）
IAP 認証（Authentication）

IAPの場合、OAuth同意画面はユーザーの身元確認（Googleアカウントでのログイン）のために使われます。「あなたのデータへのアクセスを許可しますか？」と聞いているのではなく、「あなたは user@example.com ですね」と確認しているだけです。

その後のアクセス可否の判定は、IAP側のIAMポリシー（roles/iap.httpsResourceAccessor ロール）で行われます。つまり、IAPでは認証と認可が以下のように分離されています。

このように、IAPにおけるOAuth同意画面は「認可」ではなく「認証」の役割を担っています。OAuth同意画面が求められるからといって、必ずしもユーザーデータへのアクセス許可を意味するわけではないという点を理解しておくと混乱しにくくなるかと思います。

また、IAPではデフォルトでGoogleマネージドのOAuthクライアントが使用されるため、組織内ユーザーのみのアクセスであればOAuth同意画面の手動設定は不要です。以下の場合にカスタムOAuth構成（＝OAuth同意画面の設定 + OAuthクライアントIDの作成）が必要になります。

  • 組織外のユーザーにアクセスを許可する場合
  • カスタムブランド情報を同意画面に表示したい場合
  • プロジェクトがGoogle Cloud組織に属していない場合

やってみた

実際に、組織外のユーザーにアクセスを許可すると想定して、Cloud Run + IAPを使って、OAuth同意画面の設定からアクセステストまでの一連の流れを試してみます。

前提条件

  • Google Cloudプロジェクトが作成済みであること
  • プロジェクトがGoogle Cloud組織に所属していること
  • プロジェクトに対する編集者以上の権限があること
  • gcloud CLIが利用可能であること（Cloud Shellまたはローカル環境）
  • テスト用に組織外のGoogleアカウントがあること（アクセス拒否の動作確認で使用するため）

Cloud Run + IAP で「認証としてのOAuth同意画面」を体験する

Cloud RunにIAPを設定して、OAuth同意画面が 「認証」（ユーザーの身元確認）の目的で表示される ケースを体験してみます。記事前半の「Identity-Aware Proxy(IAP) におけるOAuth同意画面」で解説したシーケンス図の内容を、実際に手を動かして確認します。

今回は組織外のユーザーにもアクセスを許可するシナリオで検証するため、GoogleマネージドOAuthではなくカスタムOAuthの構成が必要になります。

組織内のユーザーに対してアクセスを許可するシナリオの場合は、GoogleマネージドOAuthを利用することになるので、OAuth同意画面は作成する必要がありません。Cloud Run + IAPを利用して組織内のユーザーに対してアクセスを許可する検証は以下のブログで実施しているので、よろしければご確認ください。

https://dev.classmethod.jp/articles/cloud-run-identity-aware-proxy-ga/

検証の全体像

今回の検証の全体像です。
前回のブログでは、Cloud RunサービスのデプロイやIAPの設定などコンソールから作業しましたが、今回はOAuth同意画面やClient IDなどの作業以外はgcloudコマンドで実施しようと思います。

Cloud Run サービスのデプロイ + IAP 有効化

Cloud Runでは--iapフラグを指定することで、ロードバランサなしで直接IAPを有効化できます。

# Cloud Run サービスをデプロイ（IAP有効）
gcloud run deploy hello-iap \
  --region=asia-northeast1 \
  --image=us-docker.pkg.dev/cloudrun/container/hello:latest \
  --no-allow-unauthenticated \
  --iap

デプロイ実施時に、Cloud Run APIなどAPIの有効化を求められるので有効化していきます。

The following APIs are not enabled on project [XXXXXXXXXXXXXXXXXXXXXXX]:
        run.googleapis.com
Do you want enable these APIs to continue (this will take a few minutes)? (Y/n)?  Y
Enabling APIs on project [XXXXXXXXXXXXXXXXXXXXXXX]...
Operation "operations/acf.p2-XXXXXXXXXXXX-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" finished successfully.
Deploying container to Cloud Run service [hello-iap] in project [XXXXXXXXXXXXXXXXXXXXXXX] region [asia-northeast1]
API [cloudresourcemanager.googleapis.com] not enabled on project [XXXXXXXXXXXXXXXXXXXXXXX]. Would you like to enable and retry (this will take a few minutes)? (y/N)?  Y
Enabling service [cloudresourcemanager.googleapis.com] on project [XXXXXXXXXXXXXXXXXXXXXXX]...
Operation "operations/acat.p2-XXXXXXXXXXXX-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" finished successfully.
Deploying new service...                                                                                                                                                                      
  Setting IAP service agent...done                                                                                                                                                            
  Creating Revision...done                                                                                                                                                                    
  Routing traffic...done                                                                                                                                                                      
Done.                                                                                                                                                                                         
Service [hello-iap] revision [hello-iap-00001-XXX] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-iap-XXXXXXXXXXXX.asia-northeast1.run.app

デプロイが完了しました。
alt text

次に、IAPサービスエージェントにCloud Run Invokerロールを付与します。これにより、IAPが認証済みリクエストをCloud Runサービスに転送できるようになります。

# プロジェクト番号を取得
PROJECT_NUMBER=$(gcloud projects describe $(gcloud config get-value project) --format="value(projectNumber)")

# IAP サービスエージェントに Invoker ロールを付与
gcloud run services add-iam-policy-binding hello-iap \
  --region=asia-northeast1 \
  --member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-iap.iam.gserviceaccount.com \
  --role=roles/run.invoker

IAPサービスエージェントにCloud Run Invokerロールを付与できました。

Your active configuration is: [cloudshell-XXXXX]
Updated IAM policy for service [hello-iap].
bindings:
- members:
  - serviceAccount:service-XXXXXXXXXXXX@gcp-sa-iap.iam.gserviceaccount.com
  role: roles/run.invoker
etag: XXXXXXXXXXXX=
version: 1

IAPが有効化されていることを確認します。

gcloud run services describe hello-iap --region=asia-northeast1

✔ Service hello-iap in region asia-northeast1

URL:         https://hello-iap-XXXXXXXXXXXX.asia-northeast1.run.app
Ingress:     all
Iap Enabled: true
Traffic:
  100% LATEST (currently hello-iap-00001-XXX)

Scaling:          Auto (Min: 0, Max: 100)
Threat Detection: Enabled

Last updated on 2026-03-19T01:11:46.123096Z by XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
  Revision hello-iap-00001-XXX
  Container None
    Image:           us-docker.pkg.dev/cloudrun/container/hello:latest
    Port:            8080
    Memory:          512Mi
    CPU:             1000m
    Startup Probe:
      TCP every 240s
      Port:          8080
      Initial delay: 0s
      Timeout:       240s
      Failure threshold: 1
      Type:          Default
  Service account:   XXXXXXXXXXXX-compute@developer.gserviceaccount.com
  Concurrency:       80
  Timeout:           300s

出力に Iap Enabled: true が含まれているため、IAPが有効化されています。

OAuth同意画面の設定（External）+ OAuthクライアントIDの作成

次に、OAuth同意画面を設定します。今回は組織外のユーザーにアクセスを許可するため、ユーザータイプをExternalにします。

  1. Google Cloudコンソールで [Google Auth platform] > [ブランディング] に移動します

  2. 初回の場合は「開始」をクリックします

alt text

  1. アプリ情報 でアプリ名とユーザーサポートメールを入力し、「次へ」をクリックします

alt text

  1. 対象 でユーザータイプに 外部 を選択し、「次へ」をクリックします

alt text

  1. 連絡先情報 で開発者の連絡先メールアドレスを入力し、「次へ」をクリックします

alt text

  1. 終了 で Google APIサービス：ユーザーデータに関するポリシー に同意し、「作成」をクリックします

alt text

Externalを選択した場合は、テストユーザーの追加が必要です。

  1. [Audience] ページに移動し、「Add users」をクリックしてテストユーザーのメールアドレスを追加します

alt text

次に、OAuthクライアントIDを作成します。

  1. Google Cloudコンソールで [Google Auth platform] > [クライアント] に移動します

  2. 「クライアントを作成」をクリックします

alt text

  1. アプリケーションの種類 で「ウェブアプリケーション」を選択します

  2. 名前 にクライアント名を入力します（コンソール上での識別用）

  3. 認証済みのリダイレクトURI に以下の形式でIAPのリダイレクトURIを追加します。CLIENT_ID の部分は、クライアント作成後に表示されるクライアントIDに置き換えてください

https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect

alt text

  1. 「作成」をクリックします

alt text

  1. 作成されたクライアントIDとクライアントシークレットを控えておきます

alt text

カスタムOAuthクライアントを IAP に適用

作成したOAuthクライアントIDとクライアントシークレットを、IAPの設定に適用します。

# IAP OAuth設定ファイルを作成
cat << EOF > iap-oauth.yaml
accessSettings:
  oauthSettings:
    clientId: CLIENT_ID
    clientSecret: CLIENT_SECRET
EOF

# IAP にカスタムOAuthクライアントを適用
gcloud iap settings set iap-oauth.yaml \
  --project=$(gcloud config get-value project) \
  --resource-type=cloud-run \
  --region=asia-northeast1 \
  --service=hello-iap

CLIENT_ID と CLIENT_SECRET は、先ほど作成したOAuthクライアントIDとクライアントシークレットの値に置き換えてください。

適切に設定できている場合は、以下のような出力が得られます。

Your active configuration is: [cloudshell-XXXXX]
accessSettings:
  oauthSettings:
    clientId: XXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com
    clientSecretSha256: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
name: projects/XXXXXXXXXXXX/iap_web/cloud_run-asia-northeast1/services/hello-iap

外部ユーザーにアクセス権を付与

IAPで保護されたリソースにアクセスするには、roles/iap.httpsResourceAccessor ロールが必要です。

# 外部ユーザーにアクセス権を付与
gcloud iap web add-iam-policy-binding \
  --member=user:user@example.com \
  --role=roles/iap.httpsResourceAccessor \
  --region=asia-northeast1 \
  --resource-type=cloud-run \
  --service=hello-iap

ブラウザでアクセステスト

Cloud RunサービスのURLにブラウザでアクセスします。

# サービスURLを確認
gcloud run services describe hello-iap \
  --region=asia-northeast1 \
  --format="value(status.url)"

IAPにおけるOAuth同意画面は 「認証」（身元確認）の目的で表示されます。 そのため、「データへのアクセスを許可しますか？」ではなく、「アカウントを選択してください」という画面が表示されます。

テスト1: アクセス権のあるユーザー

  1. ブラウザでCloud RunサービスのURLにアクセスします
  2. OAuth同意画面が表示され、Googleアカウントでのログインを求められます

alt text

alt text
3. ログインすると、Cloud Runサービスの画面（Hello World）が表示されます

alt text

テスト2: アクセス権のないユーザー

  1. roles/iap.httpsResourceAccessor ロールが付与されていないGoogleアカウントでアクセスします

alt text

alt text

  1. OAuth同意画面でログインした後に、403 Forbidden が表示されます

alt text

テスト2の結果が重要です。OAuth同意画面でのログイン（認証）は成功しているにもかかわらず、IAMポリシーによるアクセス権の確認（認可）で拒否されています。これが、記事前半で解説した　「IAPでは認証と認可が分離されている」　ことになります。

まとめ

今回は、IAPにおけるOAuth同意画面の役割と設定について整理しました。

OAuth 2.0は本来「認可」のフレームワークですが、IAPではユーザーの身元確認（認証）のために利用され、アクセス可否の判定はIAMポリシーで行われる点は理解していただければと思います。
また、組織内ユーザーのみであればGoogleマネージドOAuthで十分ですが、組織外ユーザーにアクセスを許可する場合はOAuth同意画面の設定とOAuthクライアントIDの作成が必要になります。注意点として、Externalを選択した場合、本番公開するまではテストユーザーに登録されたアカウントしかアクセスできません。テスト中のまま運用を忘れると「アクセスがブロックされました」エラーの原因になります。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部コンサルティング部の渡邉でした！

この記事をシェアする

FacebookHatena blogX

関連記事

LBもDNSもSSL証明書も不要！Cloud Run + IAPでの社内向けサービスの限定公開がここまで楽になった
石井悠汰
2026.02.16
【アップデート】Cloud RunでIdentity-Aware Proxyを直接構成できる機能がGAされました
渡邉 光
2026.03.17
AWS Verified AccessでGoogle認証を使って、ユーザーごとにEC2へのアクセス制御をしてみた
sora
2026.01.23
Cloud Run FunctionsからAWSのリソース(S3)をアクセスキー払い出しなしで操作する
根本夏瑠
2025.02.13