Google API にアクセスするすべてのアプリは、アプリが自身の ID を正確に表していること、 Google の API サービス ユーザーが指定したインテントに データポリシーをご覧ください。デベロッパー、および Google とアプリの共有ユーザーを保護するため、同意画面 アプリケーションが Google による確認を必要とする場合があります。
アプリが以下の条件をすべて満たす場合は、検証が必要です。
- Google API Consoleでは、ユーザー用のアプリの構成が設定されています。 External のタイプ。つまり、Google アカウントを持つユーザーなら誰でも アカウント。
- アプリケーションでロゴや表示名を OAuth 同意画面。
確認済みのブランド情報を含めると、ユーザーが商品を認識する可能性が高まります。 アプリにアクセスを許可するかどうかを決定します。確認されたブランド情報は ユーザーまたは Google Workspace 管理者が後で行う取り消しの回数が減少 サードパーティ製のアプリやサービスを アクセスできる必要があります。OAuth 同意画面のブランド確認プロセスは通常、 所要時間は2 ～ 3 ビジネス 日。
ブランドの確認申請を送信しなかった場合、ユーザーはデータのリクエストに対して信頼を失う可能性があります。その結果、ユーザーの承認が減り、取り消しが増える可能性があります。
OAuth 同意画面
同意画面では、データへのアクセスをリクエストしているユーザーと、 アクセスする必要があります（図 1 のボックス 2 で示しています）。
アプリがブランドの確認プロセスを通過して承認されると、 アプリケーションの ID とユーザーデータに関するポリシーを、 付与していることがわかります。このように明確に理解すると、 アカウント所有者は、取り消しの可能性を確認する際にお客様のリクエストを承認し、アクセス権を維持します [Google アカウント] ページ。 API Console の OAuth Consent Screen page で構成したコンテンツは、次のコンポーネントに入力されます。
- アプリの名前とロゴ（図 1 のボックス 1 を参照）
- アプリ名が選択された後に表示されるユーザー サポートのメールアドレス（図のボックス 2） 1）
- プライバシー ポリシーと利用規約へのリンク（図 1 のボックス 3）
承認済みドメイン
ブランドの確認プロセスの一環として、Google は 認証情報と関連付けられるようになります。恐れ入りますが、 パブリック サフィックス: 「上部 プライベート ドメインです」というメッセージを含めます。たとえば、アプリケーションのホームページが https://sub.example.com/product に設定された OAuth 同意画面では、アカウント所有者に example.com ドメインの所有権の確認を求めます。
OAuth 同意画面エディタの [承認済みドメイン] セクションには、 [アプリドメイン] セクションの URI に使用されているプライベート ドメインです。これらのドメインには、 アプリのホームページ、プライバシー ポリシー、利用規約。[承認済みドメイン] セクション また、「ウェブ」ページで承認されたリダイレクト URI や JavaScript 生成元 application"OAuth クライアント タイプ。
次を使用して承認済みドメインの所有権を確認します: Google Search Console:Google 所有者権限を持つアカウント: ドメインをプロジェクトに関連付ける必要があります。 API Console その承認済みドメインを使用しますGoogle 検索でのドメイン所有権の確認に関する詳細 詳しくは、サイトの所有権を確認する 責任を持ちます。
適格性確認の準備の手順
Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、 ブランド確認を完了:
- アプリが 適格性確認の要件の例外
- 関連する API のブランディング要件にアプリが準拠していることを確認する。または、 説明します。たとえば、ブランドの取り扱いガイドラインをご覧ください。 有効にする必要があります
- プロジェクトの 承認済みドメイン Google Search Console。 API Console プロジェクトにオーナーまたは編集者として関連付けられている Google アカウントを使用します。
- OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。
アプリケーションのホームページの要件
ホームページが次の要件を満たしていることを確認します。
- ホームページは、サイトのログイン アクセスだけではなく、一般公開されている必要があります できます。
- 審査対象のアプリとホームページとの関連性が明確である必要があります。
- Google Play ストアや Google Play の Facebook ページ上のアプリの掲載情報へのリンクは考慮されません。 有効なアプリケーションのホームページ
アプリケーション プライバシー ポリシーのリンク要件
アプリのプライバシー ポリシーが次の要件を満たしていることを確認してください。
- プライバシー ポリシーは、 表示され、Google Cloud の OAuth 同意画面に Google API Console。ホームページには アプリの機能の説明、プライバシー ポリシーへのリンク、 同意します。
- プライバシー ポリシーでは、アプリケーションにおける Google のユーザーデータへのアクセス、およびそれらの使用、保存、共有の方法を開示する必要があります。 Google のユーザーデータの使用は、お客様が公開した方法に限定する必要があります。 開示すること。
検証用にアプリを送信する方法
Google API Console プロジェクトは、 API Console リソースをご覧ください。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ関連付けられた Google アカウント、有効な API のセット、それらの API の課金、認証、モニタリングの設定で構成されます。たとえば、1 つのプロジェクトで 1 つ以上の OAuth クライアントを格納し、それらのクライアントで使用する API を構成して アプリへのアクセスを承認する前にユーザーに表示される OAuth 同意画面。
本番環境で使用できる状態になっていない OAuth クライアントがある場合は、 検証をリクエストしているプロジェクトです。これは Google API Console。
確認プロセスを送信する手順は次のとおりです。
- アプリが Google API 利用規約、 Google API サービスのユーザーデータ ポリシー。
- プロジェクトに関連付けられたアカウントのオーナーと編集者のロールを最新の状態に保ち、 OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報は、 API Console。これにより、組織の適切なメンバーが チームに新しい要件が通知されます。
- API Consoleにアクセス OAuth Consent Screen page。
- [プロジェクト セレクタ] ボタンをクリックします。
-
表示された [選択元] ダイアログで、プロジェクトを選択します。特典を プロジェクト ID がわかっている場合は、次のようにブラウザで URL を作成できます。 形式:
https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
- [Edit App] ボタンを選択します。
- [OAuth 同意画面] ページで必要な情報を入力し、[保存して続行] ボタンを選択します。
- [スコープを追加または削除] ボタンを使用して、アプリがリクエストするスコープをすべて宣言します。「 Google ログインに必要なスコープの初期セットは、 非機密スコープ セクション追加されたスコープは、非機密の sensitive, or restrictedとして分類されます。
- アプリの関連機能に関連するドキュメントへのリンクを最大 3 つ指定します。
-
アプリに関してリクエストされた追加情報については、後続の できます。
- 指定したアプリ構成で検証が必要な場合は、検証用にアプリを送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。
アプリを送信すると、Google の Trust &安全性チームは、 追加情報や必要な手順を記載します デベロッパーの連絡先情報セクションと OAuth 同意のサポートメール 追加情報を求める画面が表示されますプロジェクトの OAuth 同意ステータスを 画面ページで、審査プロセスが進行中かどうかなど、プロジェクトの現在の審査ステータスを確認 お客様からの回答を待っている間、 は一時停止されます。
適格性確認の要件の例外
以下のセクションで説明するシナリオでアプリを使用する場合は、審査のためにアプリを送信する必要はありません。
個人的な利用
ユースケースの一例として、アプリのユーザーが自分だけの場合や、アプリを少数のユーザーしか使用しない リストがありますユーザーも少人数でも問題ないでしょう クラウド コンピューティングの 未確認アプリ 画面を開き、個人アカウントにアプリへのアクセス権を付与します。
開発環境、テスト環境、ステージング環境で使用されるプロジェクト 階層
目的 準拠するため、Google OAuth 2.0 のポリシーを 本番環境にデプロイできます。検証用アプリのみを送信することをおすすめします。 Google アカウントを持つすべてのユーザーがアプリを利用できるようにする場合は、そのため、アプリで が開発、テスト、ステージングのいずれかの段階にある場合、確認は必要ありません。
アプリが開発フェーズまたはテストフェーズの場合は、 公開ステータス デフォルトの テスト。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加したユーザーのみがアプリを使用できることを意味します。Google アカウントのリストを管理する必要があります。 さまざまなプロセスについて説明します。
サービス所有のデータのみ
アプリがサービス アカウントを使用して自身のデータにのみアクセスし、どのユーザーにもアクセスしない場合 データ（Google アカウントにリンクされているもの）がある場合は、確認のために送信する必要はありません。
サービス アカウントの概要については、このモジュールの 次のサービス アカウント: ドキュメントをご覧くださいサービス アカウントの使用方法については、以下をご覧ください。 サーバー間での OAuth 2.0 の使用 説明します。
社内専用
つまり、そのアプリは Google Workspace または Cloud Identity 内のユーザーのみが使用する 組織です。プロジェクトは組織が所有している必要があります。また、OAuth 同意画面は内部ユーザータイプ用に構成する必要があります。その場合、アプリに組織管理者の承認が必要になることがあります。対象 詳細については、以下をご覧ください。 その他の Google Workspace に関する考慮事項をご覧ください。
- 詳細: 公開され、 内部アプリケーション。
- アプリを内部としてマークする方法について詳しくは、よくある質問をご覧ください アプリに 内部専用か
ドメイン全体のインストール
Google Workspace または Cloud Identity のユーザーのみをターゲットとするアプリの予定がある場合 常にドメイン全体で インストールの場合、アプリの確認は必要ありません。これはドメイン全体で インストールすることで、ドメイン管理者はサードパーティおよび内部のアプリケーションに ユーザーのできます。組織にアプリケーションを追加できるアカウントは、組織管理者だけです。 許可リストへの登録が必要です
アプリをドメイン全体のインストールにする方法については、よくある質問をご覧ください アプリケーションに 企業アカウントを別の Google Workspace ドメインから取得する。