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