ブランドの確認のためを送信する

Google API にアクセスするすべてのアプリは、アプリが自身の ID を正確に表していること、 Google の API サービス ユーザーが指定したインテントに データポリシーをご覧ください。デベロッパー、および Google とアプリの共有ユーザーを保護するため、同意画面 アプリケーションが Google による確認を必要とする場合があります。

アプリが以下の条件をすべて満たす場合は、検証が必要です。

  • では、ユーザー用のアプリの構成が設定されています。 External のタイプ。つまり、Google アカウントを持つユーザーなら誰でも アカウント。
  • アプリケーションでロゴや表示名を OAuth 同意画面

確認済みのブランド情報を含めると、ユーザーが商品を認識する可能性が高まります。 アプリにアクセスを許可するかどうかを決定します。確認されたブランド情報は ユーザーまたは Google Workspace 管理者が後で行う取り消しの回数が減少 サードパーティ製のアプリやサービスを アクセスできる必要があります。OAuth 同意画面のブランド確認プロセスは通常、 所要時間は2 ~ 3 ビジネス 日

ブランドの確認申請を送信しなかった場合、ユーザーはデータのリクエストに対して信頼を失う可能性があります。その結果、ユーザーの承認が減り、取り消しが増える可能性があります。

同意画面では、データへのアクセスをリクエストしているユーザーと、 アクセスする必要があります(図 1 のボックス 2 で示しています)。

アプリがブランドの確認プロセスを通過して承認されると、 アプリケーションの ID とユーザーデータに関するポリシーを、 付与していることがわかります。このように明確に理解すると、 アカウント所有者は、取り消しの可能性を確認する際にお客様のリクエストを承認し、アクセス権を維持します [Google アカウント] ページ。 の OAuth で構成したコンテンツは、次のコンポーネントに入力されます。

  1. アプリの名前とロゴ(図 1 のボックス 1 を参照)
  2. アプリ名が選択された後に表示されるユーザー サポートのメールアドレス(図のボックス 2) 1)
  3. プライバシー ポリシーと利用規約へのリンク(図 1 のボックス 3)
番号付きのラベルは、プロジェクトの OAuth 同意画面のさまざまな機能を示しています
            ブランド情報が承認済みです
図 1. OAuth 同意画面のモックアップ。

承認済みドメイン

ブランドの確認プロセスの一環として、Google は 認証情報と関連付けられるようになります。恐れ入りますが、 パブリック サフィックス: 「上部 プライベート ドメインです」というメッセージを含めます。たとえば、アプリケーションのホームページが https://sub.example.com/product に設定された OAuth 同意画面では、アカウント所有者に example.com ドメインの所有権の確認を求めます。

OAuth 同意画面エディタの [承認済みドメイン] セクションには、 [アプリドメイン] セクションの URI に使用されているプライベート ドメインです。これらのドメインには、 アプリのホームページ、プライバシー ポリシー、利用規約。[承認済みドメイン] セクション また、「ウェブ」ページで承認されたリダイレクト URI や JavaScript 生成元 application"OAuth クライアント タイプ。

次を使用して承認済みドメインの所有権を確認します: Google Search Console:Google 所有者権限を持つアカウント: ドメインをプロジェクトに関連付ける必要があります。 その承認済みドメインを使用しますGoogle 検索でのドメイン所有権の確認に関する詳細 詳しくは、サイトの所有権を確認する 責任を持ちます。

適格性確認の準備の手順

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

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

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

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

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

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

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

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

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

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

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

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

  1. アプリが Google API 利用規約Google API サービスのユーザーデータ ポリシー
  2. プロジェクトに関連付けられたアカウントのオーナーと編集者のロールを最新の状態に保ち、 OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報は、 。これにより、組織の適切なメンバーが チームに新しい要件が通知されます。
  3. にアクセス OAuth 。
  4. [プロジェクト セレクタ] ボタンをクリックします。
  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。特典を プロジェクト ID がわかっている場合は、次のようにブラウザで URL を作成できます。 形式:

    ?project=[PROJECT_ID]

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

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

  11. 指定したアプリ構成で検証が必要な場合は、検証用にアプリを送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。

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

適格性確認の要件の例外

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

個人的な利用

ユースケースの一例として、アプリのユーザーが自分だけの場合や、アプリを少数のユーザーしか使用しない リストがありますユーザーも少人数でも問題ないでしょう クラウド コンピューティングの 未確認アプリ 画面を開き、個人アカウントにアプリへのアクセス権を付与します。

開発環境、テスト環境、ステージング環境で使用されるプロジェクト 階層

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

アプリが開発フェーズまたはテストフェーズの場合は、 公開ステータス デフォルトの テスト。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加したユーザーのみがアプリを使用できることを意味します。Google アカウントのリストを管理する必要があります。 さまざまなプロセスについて説明します。

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

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

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

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

社内専用

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

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

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

アプリをドメイン全体のインストールにする方法については、よくある質問をご覧ください アプリケーションに 企業アカウントを別の Google Workspace ドメインから取得する