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