概要概要

アカウントのリンクにより、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は、トークンと呼ばれる文字列を使用して、ユーザーエージェント、クライアントアプリケーション、およびOAuth2.0サーバー間で通信します。

アカウントのリンク中には、次の3種類のOAuth2.0トークンを使用できます。

  • 認証コード。アクセストークンおよび更新トークンと交換できる短期間のトークン。セキュリティ上の理由から、Googleは認証エンドポイントを呼び出して、1回限りのコードまたは非常に短命なコードを取得します。

  • アクセストークン。ベアラにリソースへのアクセスを許可するトークン。このトークンの損失から生じる可能性のある露出を制限するために、トークンの有効期間は限られており、通常は1時間ほどで期限切れになります。

  • トークンを更新します。アクセストークンの有効期限が切れたときに新しいアクセストークンと交換できる、有効期間の長いトークン。サービスがGoogleと統合されると、このトークンはGoogleによって排他的に保存され、使用されます。 Googleはトークン交換エンドポイントを呼び出して、更新トークンをアクセストークンと交換します。アクセストークンは、ユーザーデータへのアクセスに使用されます。

トークン処理

クラスター環境およびクライアントサーバー交換での競合状態は、トークンを操作するときに複雑なタイミングおよびエラー処理シナリオをもたらす可能性があります。例えば:

  • 新しいアクセストークンのリクエストを受け取り、新しいアクセストークンを発行します。同時に、以前の有効期限が切れていないアクセストークンを使用して、サービスのリソースへのアクセス要求を受け取ります。
  • 更新トークンの返信は、Googleによってまだ受信されていません(または受信されていません)。一方、以前に有効だった更新トークンは、Googleからのリクエストで使用されます。

要求と応答は、任意の順序で到着するか、クラスターで実行されている非同期サービス、ネットワークの動作、またはその他の手段のためにまったく到着しない可能性があります。

お客様とGoogleのトークン処理システム内およびシステム間での即時かつ完全に一貫した共有状態は保証されません。複数の有効な有効期限の切れていないトークンは、システム内またはシステム間で短期間共存できます。ユーザーへの悪影響を最小限に抑えるために、次のことを行うことをお勧めします。

  • 新しいトークンが発行された後でも、有効期限が切れていないアクセストークンを受け入れます。
  • トークンローテーションの更新の代替手段を使用します。
  • 複数の同時に有効なアクセストークンと更新トークンをサポートします。セキュリティのために、トークンの数とトークンの有効期間を制限する必要があります。
メンテナンスと停止の処理

メンテナンス中または計画外の停止中、Googleは認証またはトークン交換エンドポイントを呼び出して、アクセスを取得し、トークンを更新できない場合があります。

エンドポイントは、 503エラーコードと空の本文で応答する必要があります。この場合、Googleは失敗したトークン交換リクエストを限られた時間だけ再試行します。 Googleが後で更新トークンとアクセストークンを取得できる場合、失敗したリクエストはユーザーに表示されません。

アクセストークンのリクエストが失敗すると、ユーザーが開始した場合、目に見えるエラーが発生します。暗黙的なOAuth2.0フローが使用されている場合、ユーザーはリンクの失敗を再試行する必要があります。

推奨事項

メンテナンスの影響を最小限に抑えるためのソリューションはたくさんあります。考慮すべきいくつかのオプション:

  • 既存のサービスを維持し、限られた数のリクエストを新しく更新されたサービスにルーティングします。期待される機能を確認した後でのみ、すべてのリクエストを移行します。

  • メンテナンス期間中のトークンリクエストの数を減らします。

    • メンテナンス期間をアクセストークンの有効期間よりも短く制限します。

    • アクセストークンの有効期間を一時的に延長します。

      1. トークンの有効期間をメンテナンス期間より長くします。
      2. アクセストークンの有効期間の2倍の期間待機し、ユーザーが短期間のトークンをより長い期間のトークンと交換できるようにします。
      3. メンテナンスを入力してください。
      4. 503エラーコードと空の本文でトークンリクエストに応答します。
      5. メンテナンスを終了します。
      6. トークンの有効期間を通常に戻します。

Googleへの登録

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