概要概要

アカウントのリンクにより、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に通知できます。

アカウントリンクフロー

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

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

OAuthリンク(「WebOAuth」)

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

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

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

OAuthベースのアプリフリップリンク(「アプリフリップ」)

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

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

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

使い方:

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

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

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

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

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

使い方:

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

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

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

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

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

トークンの操作

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

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

代币类型

OAuth 2.0使用称为令牌的字符串在用户代理,客户端应用程序和OAuth 2.0服务器之间进行通信。

帐户链接期间可以使用三种OAuth 2.0令牌:

  • 授权码。可以交换访问权限的短期令牌和刷新令牌。为了安全起见,Google会调用您的授权端点来获取一次性使用或寿命很短的代码。

  • 访问令牌。授予承载者对资源的访问权的令牌。为了限制可能因丢失此令牌而导致的风险敞口,它的使用寿命有限,通常会在一个小时左右后过期。

  • 刷新令牌。访问令牌到期时可以交换新的访问令牌的长期令牌。当您的服务与Google集成时,此令牌将由Google专门存储和使用。 Google调用您的令牌交换端点,以将刷新令牌交换为访问令牌,这些访问令牌又用于访问用户数据。

代币处理

在使用令牌时,群集环境和客户端-服务器交换中的竞争条件可能导致复杂的时序和错误处理方案。例如:

  • 您收到一个新的访问令牌的请求,并发出一个新的访问令牌。同时,您会收到使用前一个未过期的访问令牌访问服务资源的请求。
  • 您的刷新令牌回复尚未被Google收到(或从未收到)。同时,先前有效的刷新令牌用于Google的请求中。

由于在群集中运行的异步服务,网络行为或其他方式,请求和答复可以以任何顺序到达,或者根本无法到达。

无法保证您和Google的令牌处理系统之间以及之间的即时且完全一致的共享状态。多个有效的未过期令牌可以在短时间内在系统内或系统之间共存。为了最大程度地减少对用户的负面影响,建议您执行以下操作:

  • 即使发布了更新的令牌,也要接受未过期的访问令牌。
  • 使用替代方法来刷新令牌轮换
  • 支持多个并发有效的访问和刷新令牌。为了安全起见,应限制令牌的数量和令牌的生存期。
维护和停运处理

在维护或计划外中断期间,Google可能无法调用您的授权或令牌交换端点来获取访问权限并刷新令牌。

您的端点应以503错误代码和空主体作为响应。在这种情况下,Google将在有限的时间内重试失败的令牌交换请求。如果Google以后能够获取刷新和访问令牌,则失败的请求对用户不可见。

如果用户发起访问请求失败的请求,则会导致可见错误。如果使用隐式OAuth 2.0流程,则要求用户重试链接失败。

推荐建议

有许多解决方案可以最大程度地减少维护影响。要考虑的一些选项:

  • 维护您现有的服务,并将有限数量的请求路由到您的新更新的服务。仅在确认预期功能后才能迁移所有请求。

  • 在维护期间减少令牌请求的数量:

    • 将维护周期限制为少于访问令牌生存期。

    • 临时增加访问令牌的生存期:

      1. 将令牌寿命增加到大于维护期限。
      2. 等待两次访问令牌生存期,从而使用户可以将短期令牌替换为较长令牌。
      3. 输入维护。
      4. 使用503错误代码和空主体来响应令牌请求。
      5. 退出维护。
      6. 将令牌生存期降低到正常水平。

Googleへの登録

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