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 コンソールの [ブランディング] ページで、新しいプロジェクトの 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 ポリシーに準拠していることを確認したら、ブランド確認のために送信するで確認プロセスの詳細をご覧ください。