このページは Cloud Translation API によって翻訳されました。

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 日以内であれば復元できます。

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

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

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

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

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

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

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

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

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

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

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

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

概要