クロスクライアント ID

デベロッパーがソフトウェアを構築する際、通常はウェブサーバーで実行されるモジュール、ブラウザで実行されるその他のモジュール、ネイティブ モバイルアプリとして実行されるモジュールが含まれます。通常、デベロッパーとソフトウェアを使用するユーザーは、これらのモジュールをすべて 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 の認可インフラストラクチャによって確実に認証できる場合は、同じ論理アプリケーションに対してリソースへのアクセスを 1 回以上承認するようユーザーに求めるメッセージが表示されることはありません。現在、このインフラストラクチャには、ウェブアプリ、Android アプリ、Chrome アプリ、iOS アプリ、ネイティブ デスクトップ アプリ、入力制限付きデバイスが含まれます。

クロスクライアント アクセス トークン

ソフトウェアは、コードが実行されているプラットフォームに応じて、さまざまな方法で OAuth 2.0 アクセス トークンを取得できます。詳しくは、OAuth 2.0 を使用して Google API にアクセスするをご覧ください。通常、アクセス トークンを付与する際にユーザーの承認が必要です。

幸い、Google 認可インフラストラクチャでは、同じプロジェクト内の他のユーザーを承認するかどうかを評価する際に、特定のプロジェクト内のクライアント ID に対するユーザー承認に関する情報を使用できます。

つまり、Android アプリが特定のスコープのアクセス トークンをリクエストし、リクエスト元のユーザーが同じスコープについて、同じプロジェクト内のウェブ アプリケーションにすでに承認を付与している場合、ユーザーに再度承認を求めることはありません。これは双方向で機能します。Android アプリでスコープへのアクセスが許可されている場合、ウェブ アプリケーションなど、同じプロジェクト内の別のクライアントから再度要求されることはありません。