特定の Google API（機密情報または制限付きのスコープを受け入れるもの）には、消費者データへのアクセス権限を求めるアプリに対する要件があります。制限付きスコープの追加要件では、アプリが許可されたアプリケーション タイプであることを証明し、セキュリティ評価を含む追加の審査を受ける必要があります。
API 内の制限付きスコープの適用性は、アプリで関連する機能を提供するために必要なアクセス権の程度（読み取り専用、書き込み専用、読み取りと書き込みなど）に大きく依存します。
OAuth 2.0 を使用して Google アカウントからこのデータへのアクセス権を取得する場合、スコープと呼ばれる文字列を使用して、アクセスするデータの種類と必要なアクセス権の範囲を指定します。アプリが機密情報または制限付きのスコープをリクエストする場合、アプリの使用が例外の対象となる場合を除き、確認プロセスを完了する必要があります。
制限付きスコープは、機密情報を含むスコープよりも数が少なくなっています。OAuth API の確認に関するよくある質問には、機密性の高いスコープと制限付きスコープの現在のリストが記載されています。これらのスコープは Google ユーザーデータへの広範なアクセスを提供するため、Google アカウントからスコープをリクエストする前に、スコープの確認プロセスを完了する必要があります。この要件について詳しくは、Google API サービスのユーザーデータに関するポリシー、特定の API スコープに関する追加要件、またはプロダクト固有の Google デベロッパー ページをご覧ください。制限付きスコープのデータをサーバーに保存または送信する場合は、セキュリティ評価を完了する必要があります。
制限付きスコープについて
アプリが制限付きスコープをリクエストしており、例外の対象でない場合は、Google API サービスのユーザーデータに関するポリシーの特定の API スコープの追加要件、またはプロダクトの Google デベロッパー ページに記載されているプロダクト固有の要件を満たす必要があります。これには、より広範な審査プロセスが必要です。
スコープの使用状況を把握する
- アプリで使用している、または使用する予定のスコープを確認します。既存のスコープの使用状況を確認するには、アプリのソースコードで、認可リクエストとともに送信されるスコープを調べます。
- リクエストされた各スコープがアプリの機能の意図されたアクションに必要であり、機能を提供するために必要な最小限の権限を使用していることを確認します。通常、Google API には、プロダクトの Google デベロッパー ページに、エンドポイントの参照ドキュメントがあります。このドキュメントには、エンドポイントまたはその中の特定のプロパティを呼び出すために必要なスコープが記載されています。アプリが呼び出す API エンドポイントに必要なアクセス スコープについて詳しくは、それらのエンドポイントの参照ドキュメントをご覧ください。 For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
- Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
- 各スコープの詳細（ ステータスなど）については、API ドキュメントをご覧ください。
- アプリで使用されるすべてのスコープを Cloud コンソールの データアクセス ページで宣言します。指定したスコープは、機密性の高いカテゴリまたは制限付きカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
- インテグレーションで使用されるデータに最適なスコープを見つけ、その用途を理解し、テスト環境で引き続きすべてが機能することを確認してから、検証のために送信する準備をします。
新しいスコープを必要とするアプリや新機能のリリース計画には、確認の完了に必要な時間を必ず考慮してください。これらの追加要件の 1 つは、アプリがサーバーから、またはサーバーを介して Google ユーザーデータにアクセスする場合、またはアクセスする機能を有する場合に発生します。このような場合、システムは Google が承認した独立した第三者による年次のセキュリティ評価を受ける必要があります。そのため、制限付きスコープの確認プロセスが完了するまでに数週間かかることがあります。最後に承認された OAuth 同意画面の確認以降にブランド情報が変更された場合、すべてのアプリはまず ブランドの確認の手順を完了する必要があります。通常、この手順には 2 ～ 3 営業日かかります。
許可されているアプリケーション タイプ
特定のアプリケーション タイプは、各サービスの制限付きスコープにアクセスできます。アプリケーション タイプは、プロダクト固有の Google デベロッパー ページ（Gmail API ポリシーなど）で確認できます。
アプリケーションの種類を把握し、判断するのはお客様の責任となります。ただし、アプリのアプリケーション タイプが本当に不明な場合は、アプリを検証のために送信する際に、[どのような機能を使用しますか？] の質問に対してオプションを選択しないこともできます。Google API の検証チームがアプリケーションの種類を判断します。
Security assessment
Google ユーザーの制限付きデータへのアクセスをリクエストし、サードパーティ サーバーから、またはサードパーティ サーバー経由でデータにアクセスできるアプリはすべて、Google が任命したセキュリティ評価者によるセキュリティ評価を受ける必要があります。この評価は、Google ユーザーのデータにアクセスするすべてのアプリが、データを安全に処理し、ユーザーのリクエストに応じてユーザーデータを削除する能力を備えていることを確認することで、Google ユーザーのデータを安全に保つことを目的としています。
セキュリティ評価を標準化するために、App Defense Alliance と Cloud Application Security Assessment Framework（CASA）を使用しています。
前述のとおり、検証済みの制限付きスコープへのアクセスを維持するには、アプリはコンプライアンスの再検証を受け、評価者の評価書（LOA）の承認日から少なくとも 12 か月ごとにセキュリティ評価を完了する必要があります。アプリで新しい制限付きスコープを追加する場合、以前のセキュリティ評価に含まれていなかった追加のスコープを対象とするために、アプリの再評価が必要になることがあります。
アプリの再認証の時期が来ると、Google の審査チームからメールが届きます。この年次審査についてチームの適切なメンバーに確実に通知が届くように、オーナーまたは編集者として追加の Google アカウントを Cloud Console プロジェクトに関連付けてください。また、Google Cloud コンソールの OAuth ブランディング ページで指定されているユーザー サポートとデベロッパーの連絡先メールアドレスを最新の状態に保つことも重要です。
確認の準備の手順
Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、ブランドの確認を完了するために次の手順を行う必要があります。
- アプリが確認要件の例外セクションに記載されているケースに当てはまらないことを確認します。
- アプリが関連する API またはプロダクトのブランディング要件に準拠していることを確認します。たとえば、Google ログイン スコープのブランドの取り扱いガイドラインをご覧ください。
- Google Search Console 内でプロジェクトの承認済みドメインの所有権を確認します。API Console プロジェクトに関連付けられている Google アカウントをオーナーまたは編集者として使用します。
- OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。
アプリケーションのホームページの要件
ホームページが次の要件を満たしていることを確認してください。
- ホームページは一般公開されている必要があり、サイトのログイン ユーザーのみがアクセスできる状態であってはなりません。
- 審査中のアプリとホームページの関連性が明確である必要があります。
- Google Play ストアのアプリの掲載情報や Facebook ページへのリンクは、有効なアプリのホームページとは見なされません。
アプリケーション プライバシー ポリシーのリンクの要件
アプリのプライバシー ポリシーが次の要件を満たしていることを確認します。
- プライバシー ポリシーは、ユーザーが確認できるように、アプリケーションのホームページと同じドメイン内でホストされ、Google API Console の OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明と、プライバシー ポリシーおよびオプションの利用規約へのリンクが含まれている必要があります。
- プライバシー ポリシーでは、アプリケーションにおける Google のユーザーデータへのアクセス、およびそれらの使用、保存、共有の方法を開示する必要があります。 The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Google のユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている方法に限定する必要があります。
- Review example cases of privacy policies that don't meet the Limited Use requirements.
確認を受けるためのアプリの送信方法
Google Cloud コンソール プロジェクトは、すべての Cloud コンソール リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ関連付けられた Google アカウントのセット、有効な API のセット、これらの API の請求、認証、モニタリングの設定で構成されます。たとえば、プロジェクトには 1 つ以上の OAuth クライアントを含めることができ、これらのクライアントで使用する API を構成し、ユーザーがアプリへのアクセスを承認する前に表示される OAuth 同意画面を構成できます。
OAuth クライアントのいずれかが本番環境に対応していない場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは [クライアント] ページで行うことができます。
確認を送信する手順は次のとおりです。
- アプリが Google API の利用規約と Google API サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- Cloud Console で、プロジェクトの関連アカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報を最新の状態に保ちます。これにより、新しい要件がチームの適切なメンバーに通知されます。
- Cloud コンソールの OAuth 確認センターに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
-
表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
- [アプリを編集] ボタンを選択します。
- [OAuth 同意画面] ページで必要な情報を入力し、[保存して続行] ボタンを選択します。
- [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは、非機密の
<a href="/identity/protocols/oauth2/production-readiness/sensitive-scope-verification"
sensitive, or restrictedとして分類されます。
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
-
次のステップで、アプリに関する追加情報の入力を求められます。
- Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
- Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
- If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.
-
Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.
- Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
- Show that the OAuth consent screen correctly displays the App Name.
- Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
- To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
- If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
- Select your permitted application type from the "What features will you use?" list.
- Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
- 提供したアプリ構成で検証が必要な場合は、アプリを検証用に送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。
アプリを送信すると、Google の信頼性と安全性のチームから、必要な追加情報や完了する必要がある手順についてメールで連絡があります。追加情報のリクエストについては、[デベロッパーの連絡先情報] セクションと OAuth 同意画面のサポート メールアドレスをご確認ください。プロジェクトの OAuth 同意画面のページで、プロジェクトの現在の審査ステータス（審査プロセスが一時停止して回答待ちになっているかどうかなど）を確認することもできます。
適格性確認の要件の例外
アプリが以下のセクションで説明するシナリオのいずれかに該当する場合は、審査に提出する必要はありません。
個人的な利用
ユースケースの 1 つは、アプリのユーザーが自分だけの場合や、アプリのユーザーが数人だけで、その全員が個人的に知り合いである場合です。自分と少数のユーザーは、未確認アプリの画面をスキップして、アプリへのアクセス権を個人アカウントに付与しても問題ないかもしれません。
開発、テスト、ステージングの各階層で使用されるプロジェクト
Google OAuth 2.0 ポリシーに準拠するため、テスト環境と本番環境には別々のプロジェクトを用意することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを使用できるようにしたい場合にのみ、アプリを審査に提出することをおすすめします。そのため、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。
アプリが開発段階またはテスト段階にある場合は、[公開ステータス] をデフォルト設定の [テスト] のままにしておくことができます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加されたユーザーのみが利用できることを意味します。アプリの開発またはテストに関与する Google アカウントのリストを管理する必要があります。
サービス所有のデータのみ
アプリがサービス アカウントを使用して独自のデータにのみアクセスし、ユーザーデータ（Google アカウントにリンクされている）にアクセスしない場合は、確認を送信する必要はありません。
サービス アカウントの詳細については、Google Cloud のドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。
社内専用
つまり、アプリは Google Workspace または Cloud Identity の組織内のユーザーのみが使用します。プロジェクトは組織が所有している必要があり、その OAuth 同意画面は 内部ユーザータイプ用に構成されている必要があります。この場合、アプリで組織管理者の承認が必要になることがあります。詳細については、Google Workspace に関するその他の考慮事項をご覧ください。
- 詳しくは、一般公開アプリと社内アプリをご確認ください。
- アプリを社内専用としてマークする方法については、アプリを社内専用としてマークするにはどうすればよいですか？に関するよくある質問をご覧ください。
ドメイン全体のインストール
アプリの対象を Google Workspace または Cloud Identity 組織のユーザーのみとし、常にドメイン全体のインストールを使用する場合は、アプリのブランド認証は不要です。ただし、アプリが 制限付きスコープまたは機密性の高いスコープを使用している場合は、 アプリの確認が必要です。これは、ドメイン全体のインストールでは、ドメイン管理者がサードパーティ製または内部のアプリケーションにユーザーのデータへのアクセスを許可できるためです。組織の管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。
アプリをドメイン全体のインストールにする方法については、よくある質問の別の Google Workspace ドメインの企業アカウントを持つユーザーが私のアプリケーションを使用していますをご覧ください。