概要

アカウントのリンクを使用すると、Google アカウント所有者は、迅速かつシームレスに、安全にお客様のサービスに接続できます。Google アカウント リンクを実装して、プラットフォームからのユーザーのデータを Google のアプリやサービスと共有することもできます。

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

ユーザーは、Google アカウントのリンクを使用して、アカウントをリンクしたり、リンクを解除したり、必要に応じてプラットフォームで新しいアカウントを作成したりできます。

ユースケース

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

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

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

• Google Home アプリや Google アシスタント（「OK Google、照明をオンにして」）を使用して、Google スマートホームに接続されているデバイスを管理、操作できます。

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

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

• Google アカウントのプロフィールから同意に基づいて共有されたデータを使用して、登録時に新しいアカウントに事前入力します。

サポートされている機能

Google アカウントのリンクでは、次の機能がサポートされます。

• OAuth リンク暗黙的フローを使用して、データをすばやく簡単に共有できます。

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

• 既存のユーザーをログインさせるか、Google で確認済みの新しいユーザーをプラットフォームに登録し、同意を得て、簡素化されたリンクでデータを安全に共有します。

• アプリ切り替えで手間を軽減します。信頼できる Google アプリから、1 回タップするだけで、確認済みの Android アプリまたは iOS アプリが安全に開き、1 回タップするだけでユーザーの同意が得られ、アカウントがリンクされます。

• 必要なデータのみを共有するカスタム スコープを定義してユーザーのプライバシーを保護し、データの使用方法を明確に定義してユーザーの信頼を高めます。

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

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

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

リンク プロセスでは、アカウント所有者のアカウントのリンクとデータの共有に対する同意を得た後、個々の Google アカウントの Google へのアクセス トークンを発行します。

OAuth のリンク（「Web 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 への登録

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