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

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

概要

OAuth クライアントをプロジェクト間で共有すると、組織内のすべてのアプリ向けに新しい OAuth クライアントを手動で作成する必要がなくなります。1 つの OAuth クライアントを手動で作成したら、それをプログラムで複数のアプリに割り当てることができます。

OAuth クライアントの共有は、Identity-Aware Proxy(IAP)を有効にしたいが [認証情報] ページにアクセスできないエージェントとデフォルトの OAuth クライアントを共有するためにも使用されます。

別のプロジェクトの OAuth クライアントを使用してモバイルアプリを認証することはできません。

始める前に

以下のいずれかのガイドに従って、アプリの IAP を有効にして OAuth クライアントを作成します。

現在のところ、App Engine とのクライアント共有はサポートされていません。

Compute Engine アプリへの共有クライアントの割り当て

  1. [インスタンス グループ] ページに移動して、インスタンスがインスタンス グループ内にあることを確認します。
  2. バックエンド サービスを定義します。
  3. 負荷分散を設定します。
  4. gcloud コマンドライン ツールを使用して、gcloud auth login を実行します。
  5. 表示される URL に従ってログインします。
  6. ログインしたら、表示される確認コードをコピーしてコマンドラインに貼り付けます。
  7. IAP を有効にするプロジェクトに gcloud config set project PROJECT_ID を実行します。
  8. IAP を有効にするには、[認証情報] ページにある共有クライアントの ID とシークレットを使用して、次のコマンドを実行します。

    gcloud compute backend-services update BACKEND_SERVICE_NAME  \
       --global --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
    

GKE アプリへの共有クライアントの割り当て

アプリの BackendConfig ファイルを構成する手順に従います。次のコマンドを実行するときには、共有クライアントの ID とシークレットを使用します。

kubectl create secret generic my-secret --from-literal=client_id=CLIENT_ID \
    --from-literal=client_secret=CLIENT_SECRET

リスク

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

単一障害点

1 つの OAuth クライアントを多くのアプリで使用すると、単一障害点が発生します。クライアントが誤って削除または変更されると、そのクライアントを使用するすべてのアプリが影響を受けます。

これを軽減するために、共有クライアントの重要なユースケースを満たす場合にのみクライアントを共有してください。

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

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

IAP リソースへのアクセスは Cloud Audit Logging で監視できます。クライアント シークレットが漏洩した可能性があると思われる場合は、[認証情報] ページでシークレットをリセットしてください。

このリスクを軽減するため、クライアント シークレットはパスワードと同様に保護してください。クライアント シークレットの共有を制限し、平文で保存しないようにします。

承認済みユーザーのなりすまし

クライアント シークレットが漏洩した場合、悪意のあるアプリがそのドメインに IAP 認証済みブラウザの Cookie を設定して、承認済みユーザーになりすます可能性があります。この Cookie が使用されると、IAP は漏洩したクライアント シークレットを共有するすべてのアプリでなりすましたユーザーを認証します。

このリスクを軽減するために、承認済みユーザーも共有しているリソース間でクライアントを共有しないでください。なりすましたユーザーが認証されても IAP がアクセスを承認しないようにするには、リソースごとの権限を設定してください。

ユーザー ID の収集

クライアント シークレットが漏洩した場合、悪意のあるアプリがクライアント ID を使用してアプリのユーザーの ID を収集する可能性があります。これはユーザーが悪意のあるアプリにアクセスしたときにトリガーされます。

ユーザーが IAP で保護されたアプリに初めてアクセスすると、自分の ID をアプリと共有するよう求められます。これにより、ユーザーは自分の個人情報を管理できるようになります。ユーザーが自分の ID を共有することに同意すると、Google ログイン システムはその同意を記録します。同じプロジェクト内の任意のクライアント ID からのその後のリクエストでは、IAP はユーザーに ID の再入力を求めません。

自分の ID をアプリと共有することに同意したユーザーが悪意のあるアプリにアクセスすると、同意なしに ID が直ちに共有されてしまいます。