Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

OAuth クライアントの共有方法

このページでは、OAuth クライアントを組織内の他のアプリケーションと共有する方法について説明します。

概要

OAuth クライアントをプロジェクト間で共有するとは、アプリケーションごとに新しい OAuth クライアントを作成するのではなく、複数の Identity-Aware Proxy（IAP）で保護されたアプリケーションに単一のカスタム OAuth クライアントを使用することを意味します。このアプローチは、特に多くのアプリケーションを使用する組織で管理を簡素化します。

IAP を構成するときは、次の 2 種類の OAuth クライアントのいずれかを使用できます。

Google 管理の OAuth クライアント: IAP はデフォルトでこれを自動的に使用します。この組み込みオプションでは、クライアントを手動で作成する必要はありませんが、次の 2 つの主な制限があります。
- 組織内のユーザー（内部ユーザー）のみにアクセスを許可する
- 組織のブランディングではなく、同意画面に Google Cloud ブランディングを表示する
カスタム OAuth クライアント: ユーザーが作成して管理します。このオプションでは、次のことができます。
- 複数のアプリケーション間で共有できる
- 同意画面のブランディングをカスタマイズできます
- 外部ユーザー（組織外）のアクセスをサポート

カスタム OAuth クライアントを作成すると、単一のアプリケーションで使用することも、複数のアプリケーションで共有することもできます。カスタム OAuth クライアントを共有すると、次のようなメリットがあります。

複数のクライアントの管理にかかる管理オーバーヘッドを削減する
[認証情報] ページにアクセスできないチームメンバーの IAP を簡単に有効にできます
IAP で保護されたアプリケーションへのプログラム（ブラウザ以外）によるアクセスを容易にします

OAuth クライアントの作成については、IAP 用の OAuth クライアントを作成するをご覧ください。Google 管理の OAuth クライアントの詳細については、OAuth 構成をカスタマイズして IAP を有効にするをご覧ください。

始める前に

OAuth クライアントの作成の手順に沿って新しい OAuth クライアントを作成するか、既存の OAuth クライアントを使用します。

プログラムからのアクセス

プログラムによるアクセスのために OAuth クライアントを構成すると、ブラウザ以外のアプリケーションが IAP で保護されたリソースで認証できるようになります。これにより、スクリプト、自動ジョブ、バックエンドサービスが、インタラクティブユーザーのログインなしで保護されたアプリケーションに安全にアクセスできます。

これらの認証設定は、リソース階層の任意のレベル（組織、フォルダ、プロジェクト）で適用できます。

実装手順については、プログラムによる認証ガイドと IAP 設定管理のドキュメントをご覧ください。

gcloud

OAuth クライアント ID を含む設定ファイルを用意します。

cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

gcloud iap settings set コマンドを使用して設定を適用します。

gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

コマンドの例:

# Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

ここで

SETTINGS_FILENAME: 準備した YAML ファイル。
ORGANIZATION: 組織 ID
FOLDER: フォルダ ID
PROJECT: プロジェクト ID
RESOURCE_TYPE: IAP リソースタイプ（app-engine、iap_web、compute、organization、folder）
SERVICE: サービス名（compute または app-engine リソースタイプの場合は省略可）
VERSION: バージョン名（compute には適用されません。app-engine では省略可）

API

設定の JSON ファイルを準備します。

cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

リソース名を取得します。

gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

リソース名を使用して設定を更新します。
```
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
```
ここで
- ORGANIZATION: 組織 ID
- FOLDER: フォルダ ID
- PROJECT: プロジェクト ID
- RESOURCE_TYPE: IAP リソースタイプ（app-engine、iap_web、compute、organization、folder）
- SERVICE: サービス名（compute または app-engine リソースタイプの場合は省略可）
- VERSION: バージョン名（compute には適用されません。app-engine では省略可）

構成後、構成した OAuth クライアント ID のいずれかを使用してアプリケーションにログインします。詳細については、プログラムによる認証をご覧ください。

ブラウザアクセス

Google Cloud コンソールで IAP がクライアント ID とシークレットを使用できるようにするには、次の操作を行います。

リスク

アプリ間でクライアントを共有すると便利ですが、リスクも伴います。このセクションでは、クライアントを共有する際の潜在的なリスクとその軽減方法について概説します。

単一障害点

1 つの OAuth クライアントを多くのアプリケーションで使用すると、単一の依存関係が発生します。クライアントが誤って削除または変更されると、そのクライアントを使用するすべてのアプリケーションが影響を受けます。削除した OAuth クライアントは、30 日以内であれば復元できます。

このオペレーショナルリスクを効果的に管理するには:

適切なアクセス制御を実装して、誤った変更や削除を防ぐ
clientauthconfig.clients.* 権限を使用して OAuth クライアントへのアクセスを制限する
Google Cloud 監査ログを使用して、OAuth クライアントに関連する管理アクティビティを追跡する

これは主にセキュリティリスクではなく、運用上のリスクです。適切なアクセス制御とモニタリングが実施されていれば、通常、共有 OAuth クライアントの利便性と管理上のメリットがこの考慮事項を上回ります。

クライアントシークレットの漏洩

クライアントを共有するには、クライアントシークレットを人やスクリプトと共有する必要があります。これにより、クライアントシークレットが漏洩するリスクが高まります。IAP は、アプリケーションから作成されたトークンと漏洩したクライアントシークレットから作成されたトークンを区別できません。

このリスクを軽減するには:

パスワードなどのクライアントシークレットを保護し、平文で保存しない
Secret Manager を使用して安全な認証情報管理を実装する
Cloud Audit Logging で IAP リソースへのアクセスをモニタリングする
クライアントシークレットが漏洩した場合、影響を受けるのは認証のみで、リソースへのアクセス権限には影響しません。シークレットが漏洩した疑いがある場合は、直ちにリセットしてください。

IAP で保護されたリソースへのプログラムによるアクセスには、OAuth クライアントシークレットを個々のユーザーと共有するのではなく、サービスアカウントの JWT 認証の使用を検討してください。このアプローチにより、アプリケーションの共有 OAuth クライアントのメリットを維持しながら、セキュリティ分離を強化できます。

権限スコープに関する考慮事項

OAuth クライアントを共有すると、すべてのアプリケーションが同じ権限スコープを使用します。IAP の場合、openid と email のみが必須スコープです。この考慮事項自体は重大なリスクではありませんが、次の点を理解しておくことが重要です。

OAuth は、IAP での認証（ID の検証）にのみ使用されます。認可（リソースアクセス）は、IAM ポリシーを介して個別に処理されます。
認証情報が不正使用された場合でも、攻撃者が保護されたリソースにアクセスするには、適切な IAM 権限が必要です。
クライアントを必要な openid スコープと email スコープのみに制限すると、セキュリティ上の影響を抑えることができます。

OAuth クライアントの共有方法 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要