実装したソリューションを開発環境の外にアプリのユーザーにデプロイする準備ができたら、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 を使用します。オーナーまたは編集者として、 API Console プロジェクトに関連付けられている Google アカウントを使用します。
プロジェクトで共通の共有ドメインを持つサービス プロバイダを使用している場合は、独自のドメインの使用を許可する構成を有効にすることをおすすめします。プロバイダによっては、すでに所有しているドメインのサブドメインにサービスをマッピングできる場合があります。
製品版アプリのホームページをホストする
OAuth 2.0 を使用するすべての製品版アプリには、一般公開されているホームページが必要です。アプリの潜在的なユーザーは、アプリの特長や機能について詳しく知るためにホームページにアクセスする可能性があります。既存のユーザーが既存のアクセス許可の一覧を確認し、アプリのホームページを閲覧して、アプリの特典を継続して利用していることを思い出すこともできます。
アプリのホームページには、アプリの機能の説明に加え、プライバシー ポリシーへのリンクと、オプションの利用規約へのリンクを含める必要があります。ホームページは、所有権のある確認済みのドメインに存在する必要があります。
安全なリダイレクト URI と JavaScript のオリジンを使用する
ウェブアプリ用の OAuth 2.0 クライアントは、プレーン HTTP ではなく HTTPS リダイレクト URI と JavaScript オリジンを使用してデータを保護する必要があります。Google は、安全なコンテキストから発信されていない、または安全なコンテキストに解決されない OAuth リクエストは拒否できます。
どのサードパーティのアプリケーションやスクリプトが、ページに戻るトークンやその他のユーザー認証情報にアクセスできるかを検討します。トークンデータの確認と保存に限定されたリダイレクト URI の場所によって、センシティブ データへのアクセスを制限します。
次のステップ
アプリがこのページの OAuth 2.0 ポリシーに準拠していることを確認したら、ブランドの確認のために送信するで、確認プロセスの詳細を確認してください。