実装したソリューションを開発環境からアプリのユーザーにデプロイする準備ができたら、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 Cloud 組織管理者は、組織内のすべてのプロジェクトに連絡可能な連絡先が関連付けられていることを確認する必要があります。プロジェクトの最新の連絡先情報が登録されていないと、ご対応が必要な重要なメッセージが届かない可能性があります。
識別情報を正確に示す
有効なアプリ名を指定します。必要に応じて、ユーザーに表示するロゴも指定します。このブランド情報は、アプリのID を正確に表す必要があります。アプリのブランディング情報は、OAuth から設定されます。
製品版アプリの場合、OAuth 同意画面で定義されたブランド情報は、ユーザーに表示する前に確認する必要があります。ブランド確認が完了したアプリに対して、ユーザーがアクセス権を付与する可能性が高まります。アプリの名前、ホームページ、利用規約、プライバシー ポリシーなどの基本的なアプリケーション情報は、ユーザーが既存の付与を確認する際の付与画面に表示され、組織によるアプリの使用を確認する Google Workspace 管理者にも表示されます。
アプリが自身の ID を偽装している場合や、ユーザーを欺こうとしている場合は、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 ポリシーに準拠していることを確認したら、ブランドの確認手続きを送信するで確認プロセスの詳細をご覧ください。