クロスクライアントID

開発者がソフトウェアをビルドする場合、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アプリケーションなどの同じプロジェクト内の別のクライアントからスコープへのアクセスが再度要求されることはありません。