概要

統合パスを選択する

ニーズに最適な方法を選択します。

パス 最適な用途 その他の情報
Universal Commerce Protocol（UCP） 販売者と小売業者。 UCP ドキュメント
標準アカウントのリンク スマートホーム、テレビ、YouTube。 Google ドキュメント

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

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

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

ユースケース

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

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

  • ユニバーサル コマース プロトコル（UCP）を使用して、Google ショッピングと AI サーフェス（検索、Gemini）と統合します。

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

  • Google Home アプリと Google アシスタントを使用して、Google スマートホームのコネクテッド デバイスを管理、操作する（「OK Google、照明をつけて」）。

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

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

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

サポートされている機能

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

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

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

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

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

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

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

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

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

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

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

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

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

図 1. ユーザーのスマートフォンでのウェブ OAuth によるアカウント リンク

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

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

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

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

仕組み:

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

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

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

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

OAuth ベースの Google でログインの簡素化されたリンクは、OAuth リンクの上層に Google でログインを追加します。これにより、ユーザーは Google サーフェスを離れることなくアカウントへの関連付けを完了できるため、摩擦や離脱を減らすことができます。OAuth ベースの簡素化されたリンクは、Google でログインと OAuth リンクを組み合わせることで、シームレスなログイン、アカウント作成、アカウント リンクを実現し、最高のユーザー エクスペリエンスを提供します。サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。また、トークン交換エンドポイントは JSON ウェブトークン（JWT）アサーションをサポートし、check、create、get のインテントを実装する必要があります。

仕組み:

Google はユーザー アカウントをアサートし、この情報をデベロッパーに渡します。

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

図 3. ユーザーのスマートフォンでの簡素化されたリンクによるアカウント リンク

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

ユーザーに最適なリンク エクスペリエンスを提供するため、すべてのフローを実装することをおすすめします。簡素化されたフローとアプリ切り替えフローでは、ユーザーが少ない手順でアカウントへの関連付けを完了できるため、リンクの摩擦が軽減されます。ウェブ OAuth リンクは労力が最も少なく、最初に始めるのに適しています。その後、他のリンクフローを追加できます。

トークンを操作する

Google アカウントのリンクは、OAuth 2.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 で登録する

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