概要

統合パスを選択する

ニーズに最適なパスを選択します。

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

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

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

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

ユースケース

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

機能と要件

次のマトリックスは、各リンクフローのサポートと推奨事項を定義しています。

リンクフロー 標準の機能 UCP の機能
アプリ切り替え 推奨 推奨
合理化されたリンク 推奨 推奨
OAuth リンク 必須（代替） 必須（代替）
OAuth 2.1 推奨 推奨

エージェント型開発（MCP と UCP）

大規模言語モデル（LLM）と AI エージェントでは、ユーザーデータにアクセスするための堅牢な認証が必要です。Google アカウントのリンクは、次のような新しいパラダイムをサポートしています。

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

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

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

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 リンクフローにリダイレクトされます。

図 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 に発行します。

令牌类型

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. 将令牌生命周期缩短回正常水平。

永続的なリンク

永続的なリンクは、安定した統合のためのコア要件です。これにより、一時的なネットワーク障害や定期的な認証情報の更新が発生した場合でも、ユーザー アカウントのリンクが維持されます。

永続的なリンクを実装するには、「スライディング ウィンドウ」アプローチを使用します。ローテーションするのではなく、既存の更新トークンの有効期限を延長します（RFC 6749 セクション 6 を参照）。 これにより、新しい更新トークンが発行されても Google が正常に受信または保存されない場合に発生する可能性のある競合状態や意図しないリンク解除を防ぐことができます。

Google に登録する

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