概要

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

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

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

ユースケース

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

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

• Google TV を使用して、動画や映画を再生する。

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

• 会話型アクションを使用して、ユーザーに合わせてカスタマイズされた Google アシスタントのエクスペリエンスと機能を作成する。「OK Google, Starbucks の通常の注文をして」。

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

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

サポートされる機能

以下の機能は Google アカウントのリンクに対応しています。

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

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

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

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

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

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

注: Google Identity Platform の OAuth 2.0 ドキュメントの大部分では、ユーザーの Google アカウントを使用してログインし、ユーザーに代わって Google API を呼び出すための承認を得る方法について説明します。Google アカウントのリンクは、Google サービスのユーザーがプラットフォームで認証を行い、サービスの API を呼び出すことを許可するための逆のケースを対象としています。OAuth 2.0 を使用して Google API にアクセスする場合は、OAuth 2.0 クライアント ドキュメントをご覧ください。

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

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

リンク処理中にアカウント所有者がアカウントのリンクとデータの共有に同意した後、個々の Google アカウントのアクセス トークンを発行します。

OAuth リンク設定 ('ウェブ OAuth')

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

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

注: アプリリンクと合理化されたフローの代替手段であるため、すべてのアカウント リンクの統合にウェブ OAuth の実装が必要です。

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

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

ユーザーをリンクしてアプリにリンクするための OAuth フロー。

OAuth ベースのアプリ切り替えリンクは、確認済みの Android または iOS モバイルアプリと Google プラットフォームを切り替えながら、提案されたデータアクセスの変更を確認し、プラットフォーム上のアカウントと Google アカウントをリンクするための同意をユーザーに提示する機能です。アプリ切り替えを有効にするには、認証コードフローを使用して、OAuth リンクまたは OAuth ベースの Google ログインリンクをサービスがサポートする必要があります。

アプリ切り替えは、Android と iOS の両方でサポートされています。

仕組み:

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

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

図 2. アプリ切り替えを使用したユーザーのスマートフォンでのアカウントのリンク

OAuth ベースの合理的リンク（'効率化'）

OAuth ベースの Google ログインを効率化するリンクにより、OAuth リンクの上に Google ログインが追加されるため、ユーザーは Google のサービスから離れることなくリンクプロセスを完了できるため、操作がスムーズに行えるようになります。OAuth ベースの簡素化されたリンクは、Google ログインと OAuth リンクを組み合わせることで、シームレスなログイン、アカウントの作成、アカウントのリンクにより、最適なユーザー エクスペリエンスを提供します。サービスが OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートしている必要があります。また、トークン交換エンドポイントは、JSON Web Token（JWT）アサーションをサポートし、check、create、get インテントを実装する必要があります。

注: このフロー中にユーザーが Google のサーフェスを離れることはありません。そのため、フローが正常に動作するためには、Google がサードパーティに代わって同意する必要があります。

仕組み:

Google がユーザー アカウントを表明し、この情報をユーザーに渡します。

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

図 3. ユーザーのスマートフォンでのアカウントのリンクの簡素化

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

ユーザーがすべての環境で快適に利用できるように、すべてのフローを実装することをおすすめします。合理化されたフローとアプリ切り替えフローによって、ユーザーがリンク プロセスをわずかなステップで完了できるため、リンクの負担が軽減されます。ウェブ OAuth リンクは最小限の労力で済むため、まず他のリンクフローを追加することをおすすめします。

注: 他のフローのフォールバックであるため、すべての統合にウェブ OAuth フローが必要です。

トークンの操作

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

アカウント所有者が各自のアカウントのリンクとデータの共有に同意した後、個々の 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.

Warning: Do not return a 400 error code and {"error": "invalid_grant"} body during maintenance or outages. Doing so deletes previously issued tokens and requires users to relink their accounts.

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 設定の詳細と、アカウントのリンクを有効にするには認証情報を共有する必要があります。詳しくは、登録をご覧ください。