統合パスを選択する
ニーズに最適な方法を選択します。
| パス | 最適な用途 | その他の情報 |
|---|---|---|
| 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 アカウントのプロフィールから同意を得て共有データを使用して、新しいアカウントを事前入力します。
機能と要件
次の表に、各リンクフローのサポートと推奨事項を示します。
| フローのリンク | 標準の機能 | UCP の機能 |
|---|---|---|
| アプリフリップ | 推奨 | 推奨 |
| リンクの合理化 | 推奨 | 推奨 |
| OAuth リンク | 必須（代替） | 必須（代替） |
| OAuth 2.1 | 推奨 | 推奨 |
必要なデータのみを共有するカスタム スコープを定義することで、ユーザーのプライバシーを強化し、ユーザーデータの使用方法を明確に定義することで、ユーザーの信頼を高めます。
プラットフォームでホストされているデータやサービスへのアクセス権は、アカウントのリンクを解除することで取り消すことができます。オプションのトークン取り消しエンドポイントを実装すると、Google が開始したイベントとの同期を維持できます。また、クロス アカウント保護（RISC）を使用すると、プラットフォームで発生したリンク解除イベントを 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 サーフェスに「切り替え」て戻ります。
- アプリが見つからない場合や、アプリ切り替えのアカウントへの関連付け処理中にエラーが発生した場合は、ユーザーは Streamlined または OAuth のリンクフローにリダイレクトされます。
図 2. ユーザーのスマートフォンでのアプリ切り替えによるアカウント リンク
OAuth ベースの簡略化されたリンク（「簡略化されたリンク」）
OAuth ベースの Google でログインの簡素化されたリンクは、OAuth リンクの上層に Google でログインを追加します。これにより、ユーザーは Google サーフェスを離れることなくアカウントへの関連付けを完了できるため、摩擦や離脱を減らすことができます。OAuth ベースの簡素化されたリンクは、Google でログインと OAuth リンクを組み合わせることで、シームレスなログイン、アカウントの作成、アカウントのリンクを実現し、最高のユーザー エクスペリエンスを提供します。サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。また、トークン交換エンドポイントは JSON ウェブトークン（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 トークンには、次の 3 種類があります。
認証コード 。アクセス トークンと更新トークンに交換できる有効期間の短いトークン。セキュリティ上の理由から、Google は認証エンドポイントを呼び出して、1 回限りのコードまたは有効期間の非常に短いコードを取得します。
アクセス トークン 。ベアラーにリソースへのアクセス権を付与するトークン。このトークンが失われた場合に発生する可能性のある漏洩を制限するため、有効期間は通常 1 時間程度に制限されています。
更新トークン 。アクセス トークンの有効期限が切れたときに新しいアクセス トークンと交換できる有効期間の長いトークン。サービスが Google と統合されている場合、このトークンは Google によってのみ保存および使用されます。Google はトークン交換エンドポイントを呼び出して、更新トークンをアクセス トークンと交換します。このアクセス トークンは、ユーザーデータへのアクセスに使用されます。
トークンの処理
クラスタ化された環境やクライアントとサーバー間の交換では、トークンを使用する際に競合状態が発生し、複雑なタイミングとエラー処理のシナリオが生じる可能性があります。 次に例を示します。
- 新しいアクセス トークンのリクエストを受け取り、新しいアクセス トークンを発行します。同時に、有効期限が切れていない以前のアクセス トークンを使用して、サービスのソースへのアクセスを求めるリクエストを受け取ります。
- 更新トークンの返信が Google に届いていない（または届かない）間に、 以前に有効だった更新トークンが Google からのリクエストで使用されます。
リクエストと返信は、クラスタで実行されている非同期サービス、ネットワークの動作などにより、任意の順序で到着したり、まったく到着しなかったりする可能性があります。
Google とデベロッパーのトークン処理システム内およびシステム間で、即時かつ完全に一貫した共有状態を保証することはできません。有効期限が切れていない複数の有効なトークンが、短期間にシステム内またはシステム間で共存する可能性があります。ユーザーへの悪影響を最小限に抑えるため、次のことを行うことをおすすめします。
- 新しいトークンが発行された後でも、有効期限が切れていないアクセス トークンを受け入れる。
- 更新トークンのローテーションの代替手段を使用する 。
- 複数のアクセス トークンと更新トークンを同時に有効にする。セキュリティ上の理由から、トークンの数とトークンの有効期間を制限する必要があります。
メンテナンスと停止の処理
メンテナンス中や計画外の停止中に、Google が認証エンドポイントまたはトークン交換エンドポイントを呼び出してアクセス トークンと更新トークンを取得できない場合があります。
エンドポイントは、503 エラーコードと空の本文で応答する必要があります。この場合、Google は失敗したトークン交換リクエストを一定期間再試行します。Google が後で更新トークンとアクセス トークンを取得できる場合、失敗したリクエストはユーザーに表示されません。
ユーザーが開始したアクセス トークンのリクエストが失敗すると、エラーが表示されます。暗黙的な OAuth 2.0 フローを使用している場合、ユーザーはリンクの失敗を再試行する必要があります。
推奨事項
メンテナンスの影響を最小限に抑えるための解決策は数多くあります。検討すべきオプションをいくつかご紹介します。
既存のサービスを維持し、新しく更新されたサービスにリクエストを限定的にルーティングします。想定どおりの機能が確認されたら、すべてのリクエストを移行します。
メンテナンス期間中のトークン リクエストの数を減らします。
メンテナンス期間をアクセス トークンの有効期間よりも短くします。
アクセス トークンの有効期間を一時的に延長します。
- トークンの有効期間をメンテナンス期間よりも長くします。
- アクセス トークンの有効期間の 2 倍の時間待機して、ユーザーが有効期間の短いトークンを有効期間の長いトークンと交換できるようにします。
- メンテナンスを開始します。
- トークン リクエストに対して
503エラーコードと空の本文で応答します。 - メンテナンスを終了します。
- トークンの有効期間を通常に戻します。
永続的なリンク
永続的なリンクは、安定した統合のコア要件です。これにより、ネットワークの一時的な障害や定期的な認証情報の更新が発生した場合でも、ユーザー アカウントのリンクが維持されます。
永続的なリンクを実装するには、「スライディング ウィンドウ」アプローチを使用します。つまり、更新トークンをローテーションするのではなく、既存の更新トークンの有効期限を延長します（RFC 6749 セクション 6 を参照）。これにより、新しい更新トークンが発行されたものの、Google が正常に受信または保存できなかった場合に発生する可能性のある競合状態や意図しないリンク解除を防ぐことができます。
Google で登録する
アカウント リンクを有効にするには、OAuth 2.0 の設定の詳細と、認証情報の共有が必要です。詳しくは、登録をご覧ください。