概要

アカウントのリンクを使用すると、Google アカウントの所有者は迅速かつシームレスに、安全にサービスに接続できます。Google アカウントのリンクを実装すると、ご利用のプラットフォームからのユーザーデータが Google のアプリやサービスと共有されるようになります。

安全な OAuth 2.0 プロトコルを使用すると、ユーザーの Google アカウントをプラットフォーム上のアカウントと安全にリンクし、Google のアプリケーションとデバイスにサービスへのアクセスを許可できます。

ユーザーはアカウントをリンクまたはリンク解除できます。また、Google アカウントのリンクを使用して、プラットフォーム上に新しいアカウントを作成することもできます。

ユースケース

Google アカウントのリンクを実装する理由には、以下のようなものがあります。

  • プラットフォームからのユーザーのデータを Google のアプリやサービスと共有します。

  • Google TV を使用して動画や映画のコンテンツを再生する。

  • Google Home アプリと「OK Google ライトをつけて」という Google アシスタントを使用して、Google スマートホームの接続済みデバイスを管理、操作できます。

  • 会話型アクション（「OK Google, Starbucks からいつもの商品を注文して」）を使用して、ユーザーがカスタマイズした Google アシスタントのエクスペリエンスと機能を作成します。

  • Google アカウントを特典パートナー アカウントにリンクすると、ユーザーが YouTube で対象のライブ配信を視聴して特典を獲得できるようになります。

  • 登録時に、Google アカウント プロファイルから同意のもとに共有されるデータを新しいアカウントに事前入力します。

サポートされる機能

Google アカウントのリンクでは以下の機能がサポートされています。

  • OAuth リンク暗黙的フローを使用して、迅速かつ簡単にデータを共有する。

  • OAuth リンク認可コードフローを使用してセキュリティを強化します。

  • 効率的なリンクによって、プラットフォームへの既存のユーザー ログインや新しい Google による確認済みユーザーへの登録、ユーザーの同意を得て、データを安全に共有します。

  • アプリ切り替えでストレスを軽減しましょう。信頼できる Google アプリでは、1 回のタップで検証済みの Android または iOS アプリを安全に開き、1 回のタップでユーザーの同意を得て、アカウントをリンクします。

  • 必要なデータのみを共有するカスタム スコープを定義することでユーザーのプライバシーを向上させ、データの使用方法を明確に定義することでユーザーの信頼を高めます。

  • プラットフォームでホストされているデータとサービスへのアクセスは、アカウントのリンクを解除することで取り消すことができます。オプションのトークン取り消しエンドポイントを実装すると、Google が開始したイベントとの同期を維持できます。また、クロスアカウント保護（RISC）を使用すると、プラットフォームで発生したリンク解除イベントを Google に通知できます。

アカウントのリンクのフロー

Google アカウントのリンクには 3 つのフローがあり、いずれも OAuth ベースです。OAuth 2.0 準拠の承認エンドポイントとトークン交換エンドポイントを管理または制御する必要があります。

リンクプロセスの際には、アカウントをリンクしてデータを共有することについてアカウント所有者から同意を得たうえで、個々の Google アカウントのアクセス トークンを Google に発行します。

OAuth リンク（以下「ウェブ OAuth」）

これは、ユーザーをウェブサイトに誘導してリンクを求める基本的な OAuth フローです。ユーザーはアカウントにログインするためウェブサイトにリダイレクトされます。ログインしたユーザーは、サービス上で自分のデータを Google と共有することに同意したことになります。この時点で、ユーザーの Google アカウントとサービスがリンクされます。

OAuth リンクは、認証コードと暗黙的な OAuth フローをサポートしています。サービスは、暗黙的フロー用に OAuth 2.0 準拠の認可エンドポイントをホストする必要があります。また、認可コードフローを使用する場合は、認可エンドポイントとトークン交換エンドポイントの両方を公開する必要があります。

図 1. ウェブ OAuth を使用したユーザーのスマートフォンでのアカウントのリンク

OAuth ベースのアプリ切り替えのリンク（「アプリ切り替え」）

リンクするためにユーザーをアプリに誘導する OAuth フロー。

OAuth ベースのアプリ切り替えリンクは、ユーザーが確認済み Android または iOS モバイルアプリと Google のプラットフォーム間を移動する際に、提案されたデータアクセスの変更を確認し、プラットフォームのアカウントを Google アカウントにリンクすることに同意するようユーザーに案内します。アプリ切り替えを有効にするには、サービスが認可コードフローを使用して OAuth リンクまたは OAuth ベースの Google ログイン リンクをサポートしている必要があります。

アプリ切り替えは Android と iOS の両方に対応しています。

仕組み:

Google アプリは、アプリがユーザーのデバイスにインストールされているかどうかを確認します。

  • アプリが見つかると、ユーザーはアプリに「フリップ」されます。アプリは、アカウントを Google にリンクすることについてユーザーから同意を取得してから、Google サーフェスに「フリップ」します。
  • アプリが見つからない場合や、アプリ切り替えのリンクプロセス中にエラーが発生した場合は、合理化された OAuth フローまたはウェブ OAuth フローにリダイレクトされます。

図 2. アプリ切り替えによるユーザーのスマートフォンのアカウントのリンク

OAuth ベースの合理化されたリンク（「効率的」）

OAuth ベースの Google ログインによる合理化されたリンクでは、OAuth リンクに Google ログインが追加されるため、ユーザーは Google サーフェスを離れることなくリンクプロセスを完了できるため、摩擦や離脱を減らすことができます。OAuth ベースの合理化されたリンクは、Google ログインと OAuth リンクを組み合わせることで、シームレスなログイン、アカウントの作成、アカウントのリンクなど、優れたユーザー エクスペリエンスを提供します。サービスは、OAuth 2.0 準拠の承認エンドポイントとトークン交換エンドポイントをサポートしている必要があります。また、トークン交換エンドポイントは JSON Web Token（JWT）アサーションをサポートし、check、create、get のインテントを実装する必要があります。

仕組み:

Google はユーザー アカウントをアサートし、以下の情報を渡します。

  • データベースにユーザーのアカウントが存在する場合、ユーザーはその Google アカウントとサービスのアカウントを正常にリンクします。
  • データベースにユーザーのアカウントが存在しない場合、ユーザーは Google から提供された情報（メールアドレス、名前、プロフィール写真）を使用して新しいサードパーティ アカウントを作成するか、ログインして別のメールアドレスとリンクすることを選択できます（この場合、ユーザーはウェブ OAuth 経由でサービスにログインする必要があります）。

図 3. 効率的なリンク設定によるユーザーのスマートフォンでのアカウントのリンク

どのフローを使用すればよいですか。

ユーザーが最適なリンク体験を得られるように、すべてのフローを実装することをおすすめします。合理化されたフローとアプリ切り替えフローにより、ユーザーはわずかなステップでリンクプロセスを完了できるため、リンクの負担が軽減されます。ウェブ OAuth リンクは最も手間がかからないので、他のリンクフローを追加した後で始めるのに適しています。

トークンの操作

Google アカウントのリンクは、OAuth 2.0 業界標準に基づいています。

アカウントをリンクしてデータを共有することについてアカウント所有者の同意を得る前に、個々の Google アカウントのアクセス トークンを Google に発行します。

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

  • Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

  • Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

  • Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

  • You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
  • Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

  • Accept unexpired access tokens, even after a newer token is issued.
  • Use alternatives to Refresh Token Rotation.
  • Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

  • Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

  • Reduce the number of token requests during the maintenance period:

    • Limit maintenance periods to less than the access token lifetime.

    • Temporarily increase the access token lifetime:

      1. Increase token lifetime to greater than maintenance period.
      2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
      3. Enter maintenance.
      4. Respond to token requests with a 503 error code and empty body.
      5. Exit maintenance.
      6. Decrease token lifetime back to normal.

Google への登録

OAuth 2.0 の設定の詳細と、アカウント リンクを有効にするための認証情報の共有が必要になります。詳しくは、登録をご覧ください。