プライベートなスコープの確認

アプリが Google API を使用して Google ユーザーの情報にアクセスする権限を求められた場合、データによっては、 アプリを一般公開する前に、検証プロセスを完了する必要があります。 あります。

この要件がアプリに適用されるかどうかは、主に次の 2 つの要素によって決まります。

  1. アクセスするユーザーデータの種類（公開プロフィール情報、カレンダーのエントリ、 ドライブ、特定の健康とフィットネスに関するデータなど
  2. 必要なアクセス権限のレベル（読み取り専用、読み取りと書き込みなど）。

OAuth 2.0 を使用して Google アカウントからデータにアクセスする権限を取得する場合、 スコープと呼ばれる文字列の入口です。条件 次のカテゴリに分類されたスコープを リクエストして sensitive または 制限されている場合は、適格性確認プロセスを完了する必要があります。 が例外に該当します。

機密性の高いスコープの例としては、Google カレンダーに保存された予定の読み取り、 YouTube 動画を削除することもできます。使用可能なスコープとその分類の詳細については、アプリが呼び出す API エンドポイントのリファレンス ドキュメントと、API 用に公開されている関連する認可ガイドをご覧ください。

そのためには、その機能を提供するために必要なユーザーデータへのアクセス権を最小限に抑えたスコープをリクエストする必要があります。たとえば データの読み取りのみを行うアプリは、その他の理由で、コンテンツの読み取り、書き込み、削除のアクセス権をリクエストしてはいけません。 API とその関連エンドポイントでは、狭いスコープを使用できます。Cloud Storage から Google API は、API のポリシーに従って、かつお客様が独自の方法で アプリのアクションとプライバシー ポリシーでユーザーに明示する必要があります。

キャンペーンを立ち上げる計画では、適格性確認の完了に要する時間を考慮 新しいスコープを必要とする新機能に対して 自動的に適用されます機密性の高いスコープの検証プロセス 通常、完了まで 3 ～ 5 営業日かかります。なお、アプリによっては、 ブランド 使用して認証ができません。

機密性の高いスコープについて

機密性の高いスコープは、Google アカウントがアクセス権を付与する前に Google による審査を受ける必要があります。Google Workspace 組織管理者は、機密性の高いスコープへのアクセスを制限して、組織が信頼できると明示的にマークしていない OAuth クライアント ID によるアクセスを防ぐことができます。

スコープの使用状況を把握する

  • アプリで使用しているスコープまたは使用するスコープを確認します。既存のスコープの使用状況を確認するには アプリのソースコードを調べて、認可リクエストで送信されたスコープの有無を確認する。
  • リクエストされた各スコープが、アプリ機能の意図するアクションに必要かどうかを判断します 機能を提供するために必要な最小権限を使用します。Google API は通常 プロダクトの に関するリファレンス ドキュメント Google デベロッパー ページをご覧ください。このページには、 特定のプロパティを指定できますアプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。
  • Google API から受け取るデータは、 実際にどのように API を使用するかを、アプリのアクションと 。
  • 各スコープの詳細については、API ドキュメントを参照してください。 sensitive or restricted ステータス。
  • アプリで使用するすべてのスコープを API Consoleの OAuth 同意画面 構成スコープのページです指定したスコープは、機密性の高いスコープまたは制限付きスコープのカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
  • 統合で使用されているデータに最適なスコープを見つけて、その用途を理解する テスト環境ですべてが機能することを再度確認し、 確認します。
で確認できます。 <ph type="x-smartling-placeholder">
</ph> テーブルには、API の名前、機密スコープの 1 つ、API の説明が表示されます。 把握するのに役立ちます
図 1.機密性の高い Pod の例 OAuth 同意画面の構成スコープページに表示されるスコープです。

確認の準備の手順

Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、 ブランド確認を完了:

  1. アプリが 適格性確認の要件の例外
  2. アプリが、関連する API またはプロダクトのブランディング要件に準拠していることを確認します。たとえば、ブランドの取り扱いガイドラインをご覧ください。 有効にする必要があります
  3. プロジェクトの 承認済みドメイン Google Search Console。 API Console プロジェクトにオーナーまたは編集者として関連付けられている Google アカウントを使用します。
  4. OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。

アプリケーション ホームページの要件

ホームページが次の要件を満たしていることを確認します。

  • ホームページは、サイトのログイン アクセスだけではなく、一般公開されている必要があります できます。
  • 審査対象のアプリとホームページとの関連性が明確である必要があります。
  • Google Play ストアや Google Play の Facebook ページ上のアプリの掲載情報へのリンクは考慮されません。 有効なアプリケーションのホームページ

アプリケーション プライバシー ポリシーのリンク要件

アプリのプライバシー ポリシーが次の要件を満たしていることを確認してください。

  • プライバシー ポリシーは、 表示され、Google Cloud の OAuth 同意画面に Google API Console。ホームページには アプリの機能の説明、プライバシー ポリシーへのリンク、 同意します。
  • プライバシー ポリシーでは、アプリが Google Cloud のデータにアクセスする、 Google のユーザーデータを保存、共有します。 Google のユーザーデータの使用は、お客様が公開した方法に限定する必要があります。 開示すること。

検証用にアプリを送信する方法

Google API Console プロジェクトは、すべての API Console リソースを編成します。プロジェクトは、関連付けられた一連の プロジェクト操作の実行権限を持つ Google アカウント、有効な API セット、 それらの API の請求、認証、モニタリングの設定。たとえば、1 つのプロジェクトで 1 つ以上の OAuth クライアントを格納し、それらのクライアントで使用する API を構成して アプリへのアクセスを承認する前にユーザーに表示される OAuth 同意画面。

本番環境で使用できる状態になっていない OAuth クライアントがある場合は、 検証をリクエストしているプロジェクトです。これは Google API Console。

確認プロセスを送信する手順は次のとおりです。

  1. アプリが Google API 利用規約、 Google API サービスのユーザーデータ ポリシー。
  2. プロジェクトに関連付けられたアカウントのオーナーと編集者のロールを最新の状態に保ち、 OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報は、 API Console。これにより、新しい要件が適切なチームメンバーに通知されるようになります。
  3. API Consoleにアクセス OAuth Consent Screen page。
  4. [プロジェクト セレクタ] ボタンをクリックします。

  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。特典を プロジェクト ID がわかっている場合は、次のようにブラウザで URL を作成できます。 形式:

    https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

    [PROJECT_ID] は、使用するプロジェクト ID に置き換えます。

  6. [Edit App] ボタンを選択します。
  7. OAuth 同意画面のページで必要な情報を入力し、[Save（保存） して続行] ボタンをクリックします。
  8. [スコープを追加または削除] ボタンを使用して、アプリがリクエストするスコープをすべて宣言します。「 Google ログインに必要なスコープの初期セットは、 非機密スコープ セクション追加されたスコープは非機密に分類され、 sensitive, or restricted。
  9. アプリの関連機能に関連するドキュメントへのリンクを最大 3 つ指定します。

  10. アプリに関してリクエストされた追加情報については、後続の できます。

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. 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 its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. 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.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
  11. 指定したアプリ構成で検証が必要な場合は、検証用にアプリを送信できます。必須フィールドに入力して [送信] をクリックし、 確認プロセスに進みます。

アプリを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡が届きます。[デベロッパーの連絡先情報] セクションのメールアドレスと、OAuth 同意画面のサポート用メールアドレスで、追加情報の提供を求めるリクエストを確認します。プロジェクトの OAuth 同意ステータスを 画面ページで、審査プロセスが進行中かどうかなど、プロジェクトの現在の審査ステータスを確認 お客様からの回答を待っている間、 は一時停止されます。

適格性確認の要件の例外

以降のセクションで説明するシナリオのいずれかでアプリを使用する場合、 審査のために送信する必要はありません。

個人的な利用

ユースケースの一例として、アプリのユーザーが自分だけの場合や、アプリを少数のユーザーしか使用しない リストがあります開発者自身と少数のユーザーであれば、未確認アプリの画面を進んで、個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。

開発、テスト、ステージング ティアで使用されるプロジェクト

目的 準拠するため、Google OAuth 2.0 のポリシーを 本番環境にデプロイできます。検証用アプリのみを送信することをおすすめします。 Google アカウントを持つすべてのユーザーがアプリを利用できるようにする場合は、そのため、アプリで が開発、テスト、ステージングのいずれかの段階にある場合、確認は必要ありません。

アプリが開発フェーズまたはテストフェーズの場合は、 公開ステータス デフォルトの テスト。この設定は、アプリがまだ開発中で、 テストユーザーのリストに追加したユーザーにのみ公開されます。アプリの開発やテストに関連する Google アカウントのリストを管理する必要があります。

テスト中のアプリが Google で確認されていないことを示す警告メッセージ。
図 2. テスターの警告画面

サービス所有のデータのみ

アプリがサービス アカウントを使用して自身のデータにのみアクセスし、どのユーザーにもアクセスしない場合 データ（Google アカウントにリンクされているもの）がある場合は、確認のために送信する必要はありません。

サービス アカウントの概要については、このモジュールの 次のサービス アカウント: ドキュメントをご覧くださいサービス アカウントの使用方法については、以下をご覧ください。 サーバー間での OAuth 2.0 の使用 説明します。

社内専用

つまり、このアプリは Google Workspace または Cloud Identity の組織内のユーザーのみが使用できます。プロジェクトは組織が所有している必要があり、その OAuth 同意画面 通常のショッピングキャンペーンを 内部ユーザー type。その場合、アプリに組織管理者の承認が必要になることがあります。対象 詳細については、以下をご覧ください。 その他の Google Workspace に関する考慮事項をご覧ください。

ドメイン全体のインストール

Google Workspace または Cloud Identity のユーザーのみをターゲットとするアプリの予定がある場合 常にドメイン全体で インストールの場合、アプリの確認は必要ありません。これはドメイン全体で インストールすることで、ドメイン管理者はサードパーティおよび内部のアプリケーションに ユーザーのできます。組織にアプリケーションを追加できるアカウントは、組織管理者だけです。 許可リストへの登録が必要です

アプリをドメイン全体のインストールにする方法については、よくある質問の 私のアプリには、別の Google Workspace ドメインのエンタープライズ アカウントを持つユーザーがいますをご覧ください。