概要概要

アカウントのリンクにより、Googleアカウントの所有者は、サービスにすばやくシームレスかつ安全に接続できます。プラットフォームからのユーザーのデータをGoogleアプリやサービスと共有するために、Googleアカウントリンクを実装することを選択できます。

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

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

ユースケース

Googleアカウントリンクを実装する理由のいくつかは次のとおりです。

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

• 使用して、ビデオや映画コンテンツを再生するGoogleのテレビを。

• GoogleホームアプリとGoogleアシスタントを使用して、 Googleスマートホームに接続されたデバイスを管理および制御します。

• 会話型アクション「ねぇGoogle、いつものスターバックスに注文して」を使って、ユーザーがカスタマイズしたGoogleアシスタントのエクスペリエンスと機能を作成します。

• Googleアカウントをリワードパートナーアカウントにリンクした後、YouTubeで対象となるライブストリームを表示して、ユーザーがリワードを獲得できるようにします。

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

サポートされている機能

これらの機能は、Googleアカウントリンクによってサポートされています。

• OAuth Linkingの暗黙的なフローを使用して、データをすばやく簡単に共有します。

• OAuthリンク認証コードフローでセキュリティを向上させます。

• 既存のユーザーにサインインするか、新しいGoogle検証済みユーザーをプラットフォームにサインアップして、同意を取得し、合理化されたリンクを使用してデータを安全に共有します。

• アプリフリップで摩擦を減らします。信頼できるGoogleアプリから、1回タップすると確認済みのAndroidまたはiOSアプリが安全に開き、1回タップするとユーザーの同意が得られ、アカウントがリンクされます。

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

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

注： Google IdentityPlatformのOAuth2.0ドキュメントのほとんどは、ユーザーのGoogleアカウントでログインし、ユーザーに代わってGoogleAPIを呼び出すための承認を取得する方法について説明しています。 Googleアカウントリンクは、Googleサービスのユーザーがプラットフォームで認証してサービスのAPIを呼び出すことを許可する逆のケースをカバーしています。 OAuth2.0を使用してGoogleAPIにアクセスする場合は、 OAuth2.0クライアントのドキュメントを参照してください。

アカウントリンクフロー

3つのGoogleアカウントリンクフローがあり、それらはすべてOAuthベースであり、OAuth2.0準拠の承認およびトークン交換エンドポイントを管理または制御する必要があります。

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

OAuthリンク（「WebOAuth」）

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

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

注： Web OAuthの実装は、App FlipおよびStreamlinedフローのフォールバック方法であるため、すべてのアカウントリンク統合に必要です。

図1 。 WebOAuthを使用したユーザーの電話でのアカウントリンク

OAuthベースのアプリフリップリンク（「アプリフリップ」）

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

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

App Flipは、 AndroidとiOSの両方でサポートされています。

使い方：

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

• アプリが見つかった場合、ユーザーはアプリに「反転」します。アプリは、アカウントをGoogleにリンクすることについてユーザーから同意を収集し、Googleの表面に「フリップバック」します。
• アプリが見つからない場合、またはアプリのフリップリンクプロセス中にエラーが発生した場合、ユーザーは合理化されたフローまたはWebOAuthフローにリダイレクトされます。

図2 。 AppFlipを使用したユーザーの電話でのアカウントリンク

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

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

注：このフロー中にユーザーがGoogleの表面を離れることはないため、フローが正しく機能するためには、Googleが3Pに代わって同意を示す必要があります。

使い方：

Googleはユーザーアカウントを主張し、この情報をあなたに渡します：

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

図3 。合理化されたリンクを使用したユーザーの電話でのアカウントリンク

どのフローを使用する必要がありますか？

ユーザーが最高のリンクエクスペリエンスを確実に得られるように、すべてのフローを実装することをお勧めします。合理化されたアプリのフリップフローは、ユーザーが非常に少ないステップでリンクプロセスを完了することができるため、リンクの摩擦を軽減します。 Web OAuthリンクは、労力が最も少なく、他のリンクフローを追加した後に開始するのに適した場所です。

注： Web OAuthフローは、他のフローのフォールバックであるため、すべての統合に必要です。

トークンの操作

Googleアカウントのリンクは、OAuth2.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.

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への登録

アカウントのリンクを有効にするには、OAuth2.0の設定の詳細と資格情報の共有が必要です。詳細は登録をご覧ください。