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

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

概要

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

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

  • Google 管理の OAuth クライアント: IAP はデフォルトでこれを自動的に使用します。この組み込みオプションでは、クライアントを手動で作成する必要はありませんが、次の 2 つの重要な制限があります。

    • 組織内のユーザー（内部ユーザー）のみにアクセスを許可する

    • 同意画面に組織のブランディングではなく Google Cloud ブランディングを表示します。

  • カスタム OAuth クライアント: ユーザーが作成して管理します。このオプションを選択すると、以下のことを行えます。

    • 複数のアプリケーション間で共有可能

    • 同意画面のブランディングをカスタマイズできる

    • 外部ユーザー（組織外のユーザー）のアクセスをサポート

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

  • 複数のクライアントを管理する管理オーバーヘッドを削減

  • [認証情報] ページにアクセスできないチームメンバーに対して IAP を簡単に有効にできる

  • IAP で保護されたアプリケーションへのプログラムによる（ブラウザ以外の）アクセスを容易にする

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

始める前に

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

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

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

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

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

gcloud

  1. OAuth クライアント ID を含む設定ファイルを準備します。

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

  2. 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

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

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

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

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

  3. リソース名を使用して設定を更新します。

    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 リソースへのアクセスをモニタリングする

  • クライアント シークレットの漏洩は認証にのみ影響し、リソースへのアクセス認可には影響しません。シークレットが漏洩した疑いがある場合は、すぐにリセットしてください。

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

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

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

  • OAuth は、IAP での認証（ID の確認）にのみ使用されます。認可（リソースへのアクセス）は、IAM ポリシーを介して個別に処理されます。

  • 認証情報が不正使用された場合でも、攻撃者が保護されたリソースにアクセスするには、適切な IAM 権限が必要です。

  • クライアントを必要な openid スコープと email スコープのみに制限すると、セキュリティへの潜在的な影響を抑えることができます。