OAuth 2.0 ポリシーに準拠する

このガイドでは、アプリを本番環境用に準備する際に発生する一般的なデベロッパーの問題に対処する方法について説明します。

概要

実装したソリューションを開発環境からアプリのユーザーにデプロイする準備ができたら、Google の OAuth 2.0 ポリシーに準拠するために追加の手順が必要になる場合があります。このガイドでは、アプリを本番環境用に準備する際にデベロッパーが直面する一般的な問題に対処する方法について説明します。これにより、エラーを最小限に抑えながら、できるだけ多くのユーザーにリーチできます。

テスト環境と本番環境に別々のプロジェクトを使用する

Google の OAuth ポリシーでは、テスト環境と本番環境に個別のプロジェクトが必要です。一部のポリシーと要件は、本番環境アプリにのみ適用されます。すべての Google アカウントで利用可能なアプリのプロダクション バージョンに対応する OAuth クライアントを含む、別のプロジェクトを作成して構成する必要がある場合があります。

本番環境で使用される Google OAuth クライアントは、同じアプリケーションをテストまたはデバッグする同様の OAuth クライアントよりも、安定性、予測可能性、安全性の高いデータの収集と保存の環境を提供します。本番環境プロジェクトは検証を申請できるため、特定の API スコープの追加要件（サードパーティのセキュリティ評価など）の対象となる可能性があります。

  1. Google API Console に移動します。[プロジェクトを作成] をクリックし、名前を入力して、[作成] をクリックします。
  2. このプロジェクトで、テスト階層に関連付けられている可能性がある OAuth クライアントを確認します。必要に応じて、本番環境プロジェクト内の本番環境クライアント用に同様の OAuth クライアントを作成します。
  3. クライアントで使用されているAPI を有効にします。
  4. Cloud Console の [ブランディング] ページで、新しいプロジェクトの OAuth 同意画面の構成を確認します。

本番環境で使用される Google OAuth クライアントには、自分または開発チームのみが利用できるテスト環境、リダイレクト URI、JavaScript 生成元を含めることはできません。以下に、いくつかの例を示します。

  • 個々のデベロッパーのテストサーバー
  • アプリのテスト版またはプレリリース版

プロジェクトの連絡先のリストを維持する

Google と、有効にした個々の API は、サービスの変更や、プロジェクトとそのクライアントに必要な新しい構成について、お客様に連絡する必要がある場合があります。プロジェクトの IAM リストを確認して、チームの関連するユーザーがプロジェクト構成の編集または表示権限を持っていることを確認します。これらのアカウントには、プロジェクトに必要な変更に関するメールが届くこともあります。

ロールには、プロジェクト リソースに対して特定の操作を実行できるようにする一連の権限が含まれています。プロジェクト編集者には、プロジェクトの OAuth 同意画面を変更する権限など、状態を変更するアクションの権限があります。すべての編集者権限を持つプロジェクト オーナーは、プロジェクトに関連付けられているアカウントを追加または削除したり、プロジェクトを削除したりできます。プロジェクト オーナーは、お支払い情報が設定される理由のコンテキストを提供することもできます。プロジェクト オーナーは、有料 API を使用するプロジェクトの課金情報を設定できます。

プロジェクト オーナーと編集者は最新の状態に保つ必要があります。プロジェクトに複数の関連アカウントを追加すると、プロジェクトと関連するメンテナンスへのアクセスを継続的に確保できます。プロジェクトに関する通知やサービスの更新情報がある場合は、これらのアカウントにメールが送信されます。Google Cloud 組織の管理者は、組織内のすべてのプロジェクトに連絡可能な連絡先が関連付けられていることを確認する必要があります。プロジェクトの連絡先情報が最新でない場合、対応が必要な重要なメッセージを見逃す可能性があります。

識別情報を正確に表す

有効なアプリ名と、必要に応じてユーザーに表示するロゴを指定します。このブランド情報は、アプリの身元を正確に表すものでなければなりません。アプリのブランディング情報は、OAuth のブランディング ページで設定します。

本番環境アプリの場合、OAuth 同意画面で定義されたブランド情報は、ユーザーに表示される前に確認を受ける必要があります。ブランド認証が完了すると、ユーザーがアプリへのアクセスを許可する可能性が高まります。アプリの名前、ホームページ、利用規約、プライバシー ポリシーなどの基本的なアプリ情報は、ユーザーが権限付与画面で確認するとき、既存の権限付与を確認するとき、または組織によるアプリの使用状況を確認する Google Workspace 管理者に表示されます。

Google は、身元を偽ったり、ユーザーを欺こうとしたりするアプリに対して、Google API サービスやその他の Google プロダクトやサービスへのアクセス権を取り消したり、一時停止したりすることがあります。

必要なスコープのみをリクエストする

アプリケーションの開発中に、API が提供するサンプル スコープを使用して、アプリケーション内でコンセプト実証を作成し、API の機能について詳しく学習した可能性があります。これらのスコープの例は、特定の API の考えられるすべてのアクションを包括的にカバーしているため、アプリの最終的な実装で必要となる情報よりも多くの情報をリクエストすることがよくあります。たとえば、サンプル スコープでは読み取り、書き込み、削除の権限がリクエストされる可能性がありますが、アプリケーションに必要なのは読み取り権限のみです。アプリケーションの実装に不可欠な情報に限定された関連する権限をリクエストします。

アプリが呼び出す API エンドポイントのリファレンス ドキュメントを確認し、アプリに必要な関連データにアクセスするために必要なスコープをメモします。API が提供する認可ガイドを確認し、最も一般的な使用方法を含めて、スコープをより詳細に説明します。関連する機能を動作させるためにアプリが必要とする最小限のデータアクセスを選択します。

この要件について詳しくは、OAuth 2.0 ポリシーの必要なスコープのみをリクエストするセクションと、Google API サービスのユーザー データ ポリシーの関連する権限をリクエストするセクションをご覧ください。

機密性の高いスコープまたは制限付きスコープを使用しない本番環境アプリを検証用に送信する

Google でログインでは、ユーザーの認証時に機密性の高いスコープや制限付きスコープはリクエストされません。アプリケーションが認証にのみ Google でログインを使用している場合は、ブランド検証のためにアプリケーションを送信する必要があります。Google Cloud コンソールの [ブランディング ページ] から確認を送信できます。この確認は、同意画面にアプリのブランディング要素（名前、ロゴ、プライバシー ポリシー、利用規約、スコープなど）を表示するために必要です。

ログインボタンの配置については、公式のブランディング ガイドラインに準拠することを強くおすすめします。

所有しているドメインのみを使用する

Google の OAuth 同意画面の確認プロセスでは、プロジェクトのホームページ、プライバシー ポリシー、利用規約、承認済みのリダイレクト URI、承認済みの JavaScript 生成元に関連付けられているすべてのドメインの確認が必要です。OAuth 同意画面エディタの [承認済みドメイン] セクションにまとめられている、アプリで使用されているドメインのリストを確認し、所有していないため確認できないドメインを特定します。プロジェクトの承認済みドメインの所有権を確認するには、Google Search Console を使用します。API Console プロジェクトに関連付けられている Google アカウントをオーナーまたは編集者として使用します。

プロジェクトで共通の共有ドメインを持つサービス プロバイダを使用している場合は、独自のドメインの使用を許可する構成を有効にすることをおすすめします。プロバイダによっては、サービスをすでに所有しているドメインのサブドメインにマッピングできる場合があります。

本番環境アプリのホームページをホストする

OAuth 2.0 を使用するすべての本番環境アプリには、一般公開されているホームページが必要です。アプリの潜在的なユーザーは、アプリが提供する機能について詳しく知るためにホームページにアクセスする可能性があります。既存のユーザーは、既存の付与のリストを確認し、アプリのホームページにアクセスして、引き続きサービスを利用することを思い出します。

アプリのホームページには、アプリの機能の説明と、プライバシー ポリシーおよび利用規約（任意）へのリンクを含める必要があります。ホームページは、所有権が確認済みのドメインに存在する必要があります。

安全なリダイレクト URI と JavaScript 生成元を使用する

ウェブアプリ用の OAuth 2.0 クライアントは、プレーンな HTTP ではなく、HTTPS リダイレクト URI と JavaScript 生成元を使用してデータを保護する必要があります。Google は、安全なコンテキストから発信されていない、または安全なコンテキストに解決されない OAuth リクエストを拒否できます。

トークンや、ページに返される他のユーザー認証情報にアクセスできるサードパーティ製アプリケーションやスクリプトを検討します。トークンデータの検証と保存に限定されたリダイレクト URI のロケーションを使用して、センシティブ データへのアクセスを制限します。

次のステップ

このページの OAuth 2.0 ポリシーにアプリが準拠していることを確認したら、ブランドの確認を送信するで確認プロセスの詳細をご覧ください。