OAuth 2.0 ポリシーに準拠する

実装したソリューションを開発環境以外の方法でアプリのユーザーにデプロイする準備ができたら、Google の OAuth 2.0 ポリシーに準拠するために追加の手順が必要になることがあります。このガイドでは、製品版アプリを準備する際によく見られるデベロッパーの問題に対応する方法の概要を説明します。これにより、エラーを最小限に抑えながら、できるだけ多くのオーディエンスにリーチできます。

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

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

本番環境で使用される Google OAuth クライアントは、同じアプリケーションをテストまたはデバッグする類似の OAuth クライアントよりも、より安定した、予測可能な、安全なデータ収集と保存の環境を提供できます。本番環境プロジェクトは検証のために送信できるため、特定の API スコープに関する追加の要件が適用される場合があります。これには、サードパーティのセキュリティ評価が含まれる場合があります。

  2. このプロジェクトで、テスト階層に関連付けられている可能性がある OAuth クライアントを確認します。必要に応じて、本番環境プロジェクト内の本番環境クライアント用に同様の OAuth クライアントを作成します。
  3. クライアントで使用されているAPI を有効にする。
  4. 新しいプロジェクトの OAuth 同意画面の構成を確認します。

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

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

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

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

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

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

識別情報を正確に示す

有効なアプリ名を指定します。必要に応じて、ユーザーに表示するロゴも指定します。このブランド情報は、アプリのID を正確に表す必要があります。アプリのブランディング情報は、OAuth から設定されます。

製品版アプリの場合、OAuth 同意画面で定義されたブランド情報は、ユーザーに表示する前に確認する必要があります。ブランド確認が完了したアプリに対して、ユーザーがアクセス権を付与する可能性が高まります。アプリの名前、ホームページ、利用規約、プライバシー ポリシーなどの基本的なアプリケーション情報は、ユーザーが既存の付与を確認する際の付与画面に表示され、組織によるアプリの使用を確認する Google Workspace 管理者にも表示されます。

アプリが自身の ID を偽装している場合や、ユーザーを欺こうとしている場合は、Google API サービスやその他の Google プロダクトやサービスへのアクセス権が取り消されるか、停止されることがあります。

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

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

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

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

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

一部のスコープは「sensitive」または「restricted」に分類され、審査なしで製品版アプリでは使用できません。本番環境用アプリが使用するすべてのスコープを OAuth 同意画面構成に入力します。製品版アプリで機密性の高いスコープまたは制限付きスコープを使用している場合は、スコープを認可リクエストに含める前に、それらのスコープの使用を送信して検証を受ける必要があります。

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

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

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

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

OAuth 2.0 を使用するすべての本番環境アプリには、一般公開されているホームページが必要です。アプリの潜在的なユーザーは、ホームページにアクセスして、アプリが提供する機能の詳細を確認する場合があります。既存のユーザーは、既存の権限付与のリストを確認し、アプリのホームページにアクセスして、特典の利用を継続していることを再確認できます。

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

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

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

ページに返されるトークンやその他のユーザー認証情報にアクセスできるサードパーティ製のアプリケーションやスクリプトについて検討します。リダイレクト URI の場所がトークンデータの検証と保存のみに制限されているセンシティブ データへのアクセスは制限します。

次のステップ

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