Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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 でクライアント ID とシークレットを使用できるように IAP を有効にするには、次の手順を完了します。

リスク

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

単一障害点

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

この運用上のリスクを効果的に管理するには:

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

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

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

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

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

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

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

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

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

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

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

概要