クロスクライアント 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 の認可インフラストラクチャ(現在はウェブアプリ、Android アプリ、Chrome アプリ、iOS アプリ、ネイティブ デスクトップ アプリ、制限入力デバイスなど)によってアプリケーションのコンポーネントが確実に認証される限り、同じ論理アプリケーションに対するリソースへのアクセス承認を、ユーザーに複数回求めることがなくなります。

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

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

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

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