このガイドでは、GoogleのOAuth 2.0ポリシーに準拠していないため、このアプリにログインできない問題を修正する方法について説明します。したがって、状況を乗り越えるために何時間もインターネットをサーフィンしている場合は、このブログに頼ることができます。それで、それ以上の遅延なしに始めましょう。ただし、その前に、GoogleのOAuth2.0ポリシーについて説明しましょう。
OAuthとは何ですか？
OAuth（Open Authorization）プロトコルは、インターネット技術特別調査委員会によって開発され、安全な委任アクセスを可能にします。これにより、アプリは他の誰か（エンドユーザー）によって制御されているリソースにアクセスできます。この種のアクセスには、委任されたアクセス権を表すトークンが必要です。そのため、アプリケーションは、リソースを制御するユーザーになりすますことなくアクセスできます。
このブログでは、GoogleのOAuth2.0ポリシーに準拠するためのいくつかの手順を提供しようとしました。ガイドラインに従って、本番用にアプリを準備するときに発生する最も一般的な開発者の問題に準拠できるようにします。それはあなたが限られたエラーで可能な限り多くの聴衆に到達するのを助けるでしょう。
テストと本番用に別々のプロジェクトを使用する
Google OAuthポリシーには、テストと本番用に別々のプロジェクトが必要です。一部のポリシーと要件は、本番アプリにのみ適用されます。そのため、すべてのGoogleアカウントで利用できるアプリの本番バージョンに対応するOAuthクライアントを含む別のプロジェクトを作成して構成する必要がある場合があります。
Google OAuthクライアントは本番環境で使用され、同じアプリをテストまたはデバッグする同じOAuthクライアントよりも、予測可能で安定した安全なデータ収集およびストレージ環境を提供するのに役立ちます。本番プロジェクトは検証のために送信できるため、特定のAPIスコープに対する追加の要件が適用されます。これには、おそらくサードパーティのセキュリティ評価が含まれます。
ステップ1：Google API Consoleに移動し、[プロジェクトの作成]をタップし、名前を入力して[作成]をタップします
ステップ2：次に、テスト層にリンクされている可能性のあるプロジェクトの下のOAuthクライアントを確認します。該当する場合は、本番プロジェクトの本番クライアント用に同様のOAuthクライアントを作成します。
ステップ3：次に、クライアントで使用されているAPIを有効にします
ステップ4：その後、新しいプロジェクトでOAuth同意画面の構成を確認します。
本番環境で使用されるGoogleOAuthクライアントには、テスト環境、リダイレクトURI、またはJavaスクリプトオリジンをあなたまたはあなたの開発チームだけが利用できるものにしてはなりません。いくつかの例を挙げました。
1.個々の開発者のテストサーバー
2.アプリのバージョンをテストまたはプレリリースします
プロジェクトに関連する連絡先のリストを維持する
Google、および有効にした個々のAPIは、サービスの変更またはプロジェクトとそのクライアントに必要な新しい構成について連絡する必要がある場合があります。次に、プロジェクトのIAMリストを確認して、チームの重要な人々がプロジェクト構成を編集または表示できるようにします。これらのアカウントには、プロジェクトに必要な変更に関するメールが届く場合もあることに注意してください。
ロールは、ユーザーがプロジェクトリソースに対して特定のアクションを実行できるようにする一連の権限で構成されます。プロジェクト編集者は、プロジェクトのOAuth同意画面に変更を加える機能など、状態を変更するアクションに対する権限を持っています。すべての編集者権限を持つプロジェクト所有者は、プロジェクトにリンクされているアカウントを追加または削除したり、プロジェクトを削除したりできます。プロジェクトオーナーは、請求情報が設定される理由のコンテキストを提供することもできます。プロジェクトオーナーは、有料APIを使用するプロジェクトの請求情報を設定できます。
プロジェクトオーナーと編集者は最新の状態に保つ必要があります。プロジェクトにいくつかの関連するアカウントを追加して支援することができます。プロジェクトおよび関連するメンテナンスへの継続的なアクセスを確認してください。電子メールは、プロジェクトまたは当社のサービスの更新に関する通知があるアカウントによって受信されます。 Google Cloud Organizationの管理者は、アクセス可能な連絡先が組織内のすべてのプロジェクトにリンクされていることを確認する必要があります。また、プロジェクトの最新の連絡先情報がない場合は、アクションを要求する必須のメッセージを見逃してしまう可能性があります。
警告：プロジェクトに関するタイムリーな通知に対応しないと、GoogleAPIにアクセスできなくなる可能性があります。
注意点：プロジェクトに関連する連絡先の1つは、OAuth同意画面用に構成されたユーザーサポートの電子メールです。また、ユーザーがアプリに問題を抱えている場合、またはGoogle Cloud Organizationの管理者がユーザーに代わって質問をしている場合は、連絡先に連絡できるようにこのメールアドレスが表示されます。
あなたのアイデンティティを正確に表現する
本物のアプリ名、オプションでユーザーに表示するロゴを提供する必要があります。このブランド情報は、アプリケーションのIDを正確に表す場合があります。アプリのブランド情報は、OAuth同意画面ページから構成されます。
また、本番アプリの場合、OAuth同意画面で定義されたブランド情報は、ユーザーに表示する前に確認する必要があります。ユーザーは、ブランドの確認が完了した後、アプリへのアクセスを許可する傾向があります。アプリの名前、ホームページ、利用規約、プライバシーポリシーなどの基本的なアプリケーション情報は、付与画面でユーザーに表示され、ユーザーが既存の付与を確認するとき、または組織によるアプリの使用を確認するGoogleWorkspaceAdministratorに表示されます。
Googleは、IDを偽造したり、ユーザーを誤解させようとしたりするアプリについて、GoogleAPIサービスやその他のGoogle製品やサービスへのアクセスを取り消すか一時停止することができます。
必要なスコープのみをリクエストする
アプリケーションの開発中に、APIが提供するスコープの例を使用して、APIの特徴と機能についてさらに学習するために、アプリケーション内で概念実証を行った可能性があります。これらのサンプルスコープは、特定のAPIで可能なすべてのアクションを幅広くカバーしているため、アプリのニーズの最終的な実装よりも多くの情報を要求することがよくあります。
例：スコープの例では、読み取り/書き込みと削除のアクセス許可を要求できますが、アプリケーションには読み取りアクセス許可のみが必要です。関連するアクセス許可の要求は、アプリケーションの実装に不可欠な重要な情報に限定されます。
次に、アプリが呼び出すAPIエンドポイントのリファレンスドキュメントを確認し、アプリが必要とする関連データにアクセスするために必要なスコープに注意してください。次に、APIが提供する承認ガイドを確認し、最も一般的な使用法を含めるためにスコープをより詳細に説明します。関連する機能を強化するためにアプリケーションが必要とする最小限のデータアクセスを選択します。
検証に機密または限定されたスコープを使用する本番アプリを送信する
特定のスコープは「機密」または「制限付き」に分類され、レビューなしで本番アプリで使用することはできません。本番アプリが使用するすべてのスコープをOAuth同意画面構成に入力する必要があります。本番アプリで機密スコープまたは限定スコープを使用している場合は、承認リクエストにスコープを含める前に、検証のためにスコープの使用を送信する必要があることに注意してください。
所有しているドメインのみを使用する
GoogleのOAuth同意画面の検証プロセスでは、プロジェクトのホームページ、プライバシーポリシー、利用規約、承認されたリダイレクトURI、または承認されたJavaスクリプトのオリジンに関連するすべてのドメインを検証する必要があります。次に、アプリで使用されているドメインのリストを確認し、OAuth同意画面エディターの[承認済みドメイン]セクションに要約します。次に、所有していないために確認できないドメインを認識します。プロジェクトの承認済みドメインの所有権を確認するには、Google検索コンソールを使用します。その後、APIコンソールプロジェクトに関連するGoogleアカウントを所有者または編集者として使用します。
また、プロジェクトで通常の共有ドメインを持つサービスプロバイダーを使用している場合は、独自のドメインの使用を許可する可能性のある構成を有効にすることをお勧めします。一部のプロバイダーは、既に所有しているドメインのサブドメインにサービスをマッピングすることを提案しています。
セキュアリダイレクトURIとJavaScriptオリジンを使用する
WebページのOAuth2.0クライアントは、プレーンHTTPではなくHTTPSリダイレクトURIとJavaScriptオリジンを使用するデータを保護する必要があります。 Googleは、安全なコンテンツから開始したり、安全なコンテンツに解決したりしないOAuthリクエストを拒否できます。
次に、サードパーティのアプリケーションとスクリプトのどれが、そのページに戻るトークンと他のユーザークレデンシャルにアクセスできるかを検討します。機密データへのアクセスを制限すると、トークンデータの検証と保存に制限されているURIの場所がリダイレクトされます。
次のステップ
ページでアプリがOAuth2.0ポリシーに準拠していることを確認したら、検証プロセスの詳細について、ブランド検証のために送信を参照してください。
結論
このアプリはGoogleのOAuth2.0ポリシーに準拠していないため、ログインできません。あなたがブログを気に入ってくれたことを願っています。読んでくれてありがとう。