開発者がソフトウェアをビルドする場合、Webサーバーで実行されるモジュール、ブラウザーで実行される他のモジュール、およびネイティブモバイルアプリとして実行される他のモジュールが日常的に含まれます。開発者とソフトウェアを使用する人々の両方が、通常、これらすべてのモジュールを単一のアプリの一部と見なします。
GoogleのOAuth2.0実装は、この世界観をサポートしています。 OAuth2.0ベースのサービスを使用するには、Google API Consoleでソフトウェアをセットアップする必要があります。 API Consoleの編成単位は「プロジェクト」であり、マルチコンポーネントアプリに対応できます。プロジェクトごとにブランド情報を提供でき、アプリがアクセスするAPIを指定する必要があります。マルチコンポーネントアプリの各コンポーネントは、API Consoleで生成される一意の文字列であるクライアントIDによって識別されます。
クロスクライアント認証の目標
アプリが認証にOAuth2.0を使用する場合、アプリはユーザーに代わって動作し、リソースへのアクセス用にOAuth 2.0アクセストークンを要求します。このトークンは、アプリが1つ以上のスコープ文字列で識別します。通常、ユーザーはアクセスを承認するように求められます。
ユーザーが特定のスコープでアプリへのアクセスを許可すると、ユーザーはGoogle API Consoleで設定したプロジェクトレベルの製品ブランドを含むユーザー同意画面を見ています。したがって、Googleは、ユーザーがプロジェクト内の任意のクライアントIDに特定のスコープへのアクセスを許可した場合、その許可は、そのスコープのアプリケーション全体に対するユーザーの信頼を示していると見なします。
その結果、アプリケーションのコンポーネントがGoogleの承認インフラストラクチャ（現在はウェブアプリ、Androidアプリ、Chromeを含む）によって確実に認証できる場合は常に、同じ論理アプリケーションのリソースへのアクセスを複数回承認するようにユーザーに求める必要はありません。アプリ、iOSアプリ、ネイティブデスクトップアプリ、入力制限付きデバイス。
クロスクライアントアクセストークン
ソフトウェアは、コードが実行されているプラットフォームに応じて、さまざまな方法でOAuth2.0アクセストークンを取得できます。詳細については、「 OAuth2.0を使用したGoogleAPIへのアクセス」を参照してください。通常、アクセストークンを付与するときは、ユーザーの承認が必要です。
幸い、Google承認インフラストラクチャでは、同じプロジェクト内の他のユーザーを承認するかどうかを評価するときに、特定のプロジェクト内のクライアントIDのユーザー承認に関する情報を使用できます。
その結果、Androidアプリが特定のスコープのアクセストークンをリクエストし、リクエストしたユーザーが同じプロジェクトの同じスコープのWebアプリケーションにすでに承認を与えている場合、ユーザーは再度承認を求められることはありません。これは両方の方法で機能します。Androidアプリでスコープへのアクセスが許可されている場合、Webアプリケーションなどの同じプロジェクト内の別のクライアントからスコープへのアクセスが再度要求されることはありません。