実装したソリューションを開発環境を超えてアプリユーザーにデプロイする準備ができたら、Google の OAuth 2.0 ポリシーを遵守するための追加の手順が必要になることがあります。このガイドでは、アプリを本番環境用に準備する際に発生する最も一般的なデベロッパーの問題に対応する方法について説明します。これにより、エラーを抑えつつ、可能な限り多くのユーザーにリーチできます。
- テストと本番環境に別々のプロジェクトを使用する
- プロジェクトに関連する連絡先のリストを維持する
- 身元を正確に示す
- 必要なスコープのみをリクエストする
- 機密性の高い、または制限付きのスコープを使用する本番環境アプリを送信して確認を受ける
- 所有しているドメインのみを使用する
- 本番環境用ホームページをホストする
- 安全なリダイレクト URI と JavaScript 生成元を使用する
テストと本番環境に別々のプロジェクトを使用する
Google の OAuth ポリシーでは、テストと本番環境で別々のプロジェクトが必要です。一部のポリシーと要件は、本番環境アプリにのみ適用されます。すべての Google アカウントで利用可能なアプリの製品版バージョンに対応する OAuth クライアントを含む別のプロジェクトを作成し、設定する必要がある場合があります。
本番環境で使用される Google OAuth クライアントを使用すると、同じアプリケーションをテストまたはデバッグする同様の OAuth クライアントよりも安定した、予測可能で、安全なデータ収集とストレージ環境を実現できます。本番環境プロジェクトは、検証のために提出できるため、特定の API スコープに関する追加要件（第三者によるセキュリティ評価を含む）が適用されることがあります。
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- このプロジェクト内の、テスト階層に関連付けられている可能性のある OAuth クライアントを確認します。必要に応じて、本番環境プロジェクト内で本番環境クライアント用に同様の OAuth クライアントを作成します。
- クライアントで使用中の API をすべて有効にします。
- 新しいプロジェクトの OAuth 同意画面の構成を確認します。
本番環境で使用される Google OAuth クライアントには、デベロッパーや開発チームのみが利用できるテスト環境、リダイレクト URI、JavaScript 生成元を含めることはできません。次に例を示します。
- 個々のデベロッパーのテストサーバー
- アプリのテストまたはプレリリース版
プロジェクトに関連する連絡先のリストを管理する
Google および有効にした個々の API から、そのサービスの変更や、プロジェクトやクライアントに必要な新しい構成について通知を受けることがあります。プロジェクトの IAM リスティングを確認して、チームの他のユーザーがプロジェクト構成を編集または表示できるようにします。これらのアカウントには、プロジェクトに必要な変更に関するメールも届く場合があります。
ロールには、プロジェクト リソースに対して特定の操作を実行できるようにする一連の権限が含まれています。プロジェクト編集者には、プロジェクトの OAuth 同意画面に変更を加える権限など、状態を変更するアクションの権限があります。すべての編集者権限を持つプロジェクト オーナーは、プロジェクトに関連付けられたアカウントの追加または削除、プロジェクトの削除を行うことができます。プロジェクト オーナーは、お支払い情報が設定されている理由も示せます。プロジェクト オーナーは、有料の API を使用するプロジェクトの課金情報を設定できます。
プロジェクト オーナーと編集者は、常に最新の状態に保つ必要があります。複数の関連アカウントをプロジェクトに追加すると、プロジェクトやその関連メンテナンスへの継続的なアクセスを確保できます。プロジェクトに関する通知や Google サービスの更新があった場合、それらのアカウントにメールが送信されます。Google Cloud 組織管理者は、到達可能な連絡先が組織内のすべてのプロジェクトに関連付けられていることを確認する必要があります。最新の連絡先情報がプロジェクトにない場合、対応が必要な重要なメッセージを見逃す可能性があります。
識別情報を正確に示す
有効なアプリ名と、必要に応じてユーザーに表示するロゴを指定します。このブランド情報は、アプリの識別情報を正確に表す必要があります。アプリのブランディング情報は OAuth Consent Screen pageから設定します。
本番環境用アプリでは、OAuth 同意画面で定義したブランド情報をユーザーに表示する前に、検証を行う必要があります。ブランドの確認が完了した後、ユーザーがアプリへのアクセス権を付与する可能性が高くなります。基本的なアプリ情報（アプリの名前、ホームページ、利用規約、プライバシー ポリシーなど）は、ユーザーが付与されている権限を確認するとき、または組織が所有するアプリを確認する Google Workspace 管理者に対して、それらのユーザーに表示されます。
Google は、ユーザーの身元を偽ったり、ユーザーを欺こうとするアプリに対して、Google API サービスやその他の Google プロダクトへのアクセス権を取り消したり、停止することがあります。
必要なスコープのみをリクエストする
アプリケーションの開発時に、API が提供するサンプル スコープを使用して、アプリケーション内で概念実証を作成し、API の特長や機能の詳細を確認したこともあります。多くの場合、これらのスコープは、特定の API で考えられるすべてのアクションを包括的にカバーしているため、アプリの最終的な実装よりも多くの情報をリクエストします。たとえば、この例のスコープでは、読み取り権限、書き込み権限、削除権限がリクエストされる一方で、アプリケーションは読み取り権限のみを必要とします。アプリケーションの実装に不可欠な重要な情報に限定した関連する権限をリクエストします。
アプリが呼び出す API エンドポイントのリファレンス ドキュメントを確認して、アプリに必要な関連データにアクセスするために必要なスコープをメモしておきます。API が提供する承認ガイドを確認し、そのスコープを詳細に説明して、最も一般的な使用法を含めます。アプリケーションが関連機能を強化するために必要な最小限のデータアクセスを選択します。
この要件の詳細については、OAuth 2.0 ポリシーの必要なリクエスト スコープのみのセクションと、Google API サービスのユーザーデータ ポリシーの関連する権限のリクエストのセクションをご覧ください。
機密性の高いスコープや制限付きのスコープを使用する本番環境アプリを送信して確認を受ける
特定のスコープは「機密」または「制限付き」に分類され、審査なしで製品版アプリでは使用できません。本番環境アプリで使用しているすべてのスコープを OAuth 同意画面の設定に入力します。本番環境アプリで機密性の高いスコープや制限付きスコープを使用している場合は、スコープをリクエストで使用する前に、それらのスコープの使用を送信して確認する必要があります。
所有しているドメインのみを使用する
Google の OAuth 同意画面の確認プロセスでは、プロジェクトのホームページ、プライバシー ポリシー、利用規約、承認済みのリダイレクト URI、または承認済みの JavaScript 生成元に関連付けられているすべてのドメインの所有権を証明する必要があります。OAuth 同意画面エディタの [承認済みドメイン] のセクション（アプリで使用されているドメイン）の一覧を確認し、所有していないために確認できないドメインを特定します。プロジェクトの承認済みドメインの所有権を確認するには、Google Search Console を使用します。プロジェクトに関連付けられている Google アカウントをオーナーまたは編集者として使用します。 API Console
プロジェクトで共通の共有ドメインを含むサービス プロバイダを使用している場合は、独自のドメインの使用を許可する構成を有効にすることをおすすめします。プロバイダによっては、すでに所有しているドメインのサブドメインにサービスをマッピングすることを提案する場合もあります。
製品版アプリのホームページをホストする
OAuth 2.0 を使用するすべての本番環境アプリには、一般公開されるホームページが必要です。アプリの潜在的ユーザーは、ホームページにアクセスして、アプリが提供する特長や機能の詳細を確認できます。既存のユーザーは、既存の許可のリストを確認して、引き続きアプリを使用するリマインダーとしてアプリのホームページにアクセスします。
アプリのホームページには、アプリの機能の説明のほか、プライバシー ポリシーや利用規約（省略可）へのリンクを記載する必要があります。ホームページが、所有権のある確認済みドメインに存在している必要があります。
安全なリダイレクト URI と JavaScript 生成元を使用する
ウェブアプリ用の OAuth 2.0 クライアントは、プレーン HTTP ではなく HTTPS リダイレクト URI と JavaScript 生成元を使用してデータを保護する必要があります。Google では、安全なコンテキストではない、または安全なコンテキストに解決されない OAuth リクエストを拒否することができます。
トークンと、ページを返すその他のユーザー認証情報にアクセスできるサードパーティ製アプリケーションとスクリプトを検討します。リダイレクト URI の場所を使用して機密データへのアクセスを制限し、トークンデータの検証と保存に制限します。
次のステップ
アプリがこのページの OAuth 2.0 ポリシーを遵守していることを確認したら、ブランドの確認のために送信で検証プロセスの詳細を確認します。