認証ユーザーフロー

概要

認証フローの目的は、ユーザーを識別し、決済インテグレータ（インテグレータ）に対して認証することです。

認証は、他の方法の入力になります。特に associateAccount と capture に当てはまります。つまり、この 2 つの方法の入力（パラメータ）として認証の証明が使用されます。

Google では、スタンドアロン モードでの認証フローを使用してユーザーを確認することもできます。この場合、他のフローへの入力としては使用されず、ユーザーがこの ID を認証できることを確認することのみを目的として使用されます。

オンボーディング時に、Google はパートナー様と協力して、プロダクトに最適な認証メカニズムを選択できることにご注意ください。

フローの仕組み

ユーザーを認証する方法は 2 つあり、それぞれに独自のフローがあります。統合時に、インテグレータがどちらを使用するかを決定する必要があります。

  1. リダイレクト認証
  2. SMS-MT OTP 認証

リダイレクト認証

認証を必要とする Google ユーザーは、本人確認を行うためにインテグレーターのアプリまたはウェブサイトにリダイレクトされることがあります。このフローの手順の概要は次のとおりです。

  1. Google は、ユーザーをインテグレーターのウェブアプリまたは Android アプリにリダイレクトします。そこでユーザーは認証されます。
  2. 認証では、認証 requestId（AuthenticationRequest から）が認証の証明として使用されます。
  3. これにより、AuthenticationResponse と呼ばれる署名付きレスポンスが生成されます。
  4. その後、アプリやウェブサイトはユーザーを Google にリダイレクトします。

リダイレクト認証では、HTTP GET メソッドが使用され、ウェブ アプリケーション向けに URL にパラメータがエンコードされています。Android アプリの認証に Android インテントを使用します。エンコードの詳細についてはウェブ認証を、Android インテント パラメータの詳細については Android 認証をご覧ください。

これらの各認証メカニズムから、AuthenticationResponse という署名付きレスポンスが返されます。このインテントには、認証の成功を伝える、暗号化およびエンコードされた Google Standard Payments 認証レスポンス（gspAuthenticationResponse）を含める必要があります。スタンドアロン モードで使用する場合は、gspResult と署名を使用して認証が成功したかどうかが判断されます。

次のシーケンス図は、ユーザーのブラウザ、Google、インテグレータのウェブ アプリケーションの間の通信を示しています。

リダイレクト ウェブの認証フロー

ウェブ認証フロー

以下は、オブジェクトとそれらが表すもののリストです。

  • ユーザー: Google アカウントにお支払い方法を追加するユーザーです。
  • Google UI: このケースでは、お客様がお支払い方法の設定を開始する Google のウェブ インターフェース。
  • Google サーバー: 認証チェックとその他の認証タスクを行う Google のバックエンド サーバー。
  • 決済インテグレータ ウェブ: ユーザーがアカウントを持っているインテグレータのウェブサイト。

この認証フローでは、ユーザーが Google のウェブサイト（Google UI）でお支払い方法を追加しようとしていることが前提となります。すべてはここから始まります。

  1. Google UI で認証 URL が作成され、Google サーバー（バックエンド）に送信されます。これが認証プロセスをトリガーします。
  2. Google サーバーが認証リクエスト（AuthenticationRequest）を作成します。
  3. Google UI に送信された認証リクエスト。
  4. インテグレータで ID を認証するよう求めるメッセージがユーザーに表示されます。
  5. ユーザーが認証を希望していると応答すると、そのメッセージがインテグレーターのウェブサイトに送信されます。
  6. 決済インテグレータのウェブサイトで、お客様の本人確認を求められています。
  7. ユーザーが身元を証明するものを提出します。これは決済インテグレーターのウェブサイトに送信されます。
  8. インテグレータは、提供された証拠に対するレスポンス（authenticationResponse）を作成します（メッセージには authenticationResponse がエンコードされます）。
  9. このレスポンス URL がユーザーに送信されます。
  10. レスポンス URL はすぐにユーザーから Google UI に送信されます。
  11. Google UI が Google サーバーにレスポンスを送信します。
  12. Google サーバーはレスポンスを確認済みと解釈します。

次のシーケンス図は、ユーザーのスマートフォン、Google、インテグレータの Android アプリの間のやり取りを示しています。

リダイレクト - Android アプリの認証フロー

Android アプリの認証フロー

オブジェクトとそれぞれが表す内容を次に示します。

  • ユーザー: Google アカウントにお支払い方法を追加するユーザーです。
  • Google UI: ユーザーがアプリのインターフェース。ここでお客様がお支払い方法の設定を開始します。
  • Google サーバー: 認証チェックとその他の認証タスクを行う Google のバックエンド サーバー。
  • 決済インテグレータ APK: ユーザーがインテグレータ アカウントにアクセスできるインテグレータのアプリ。
  • 決済インテグレータ サーバー: ユーザーの情報が保存されているインテグレータのバックエンド サーバー。

これは認証フローであるため、すでにユーザーがアプリ（Google UI）を使用して、お支払い方法を追加しようとしていると仮定します。ここから初期化を開始します。

  1. Google UI で認証呼び出しが作成され、Google サーバー（バックエンド）に送信されます。
  2. Google サーバーが認証リクエスト（AuthenticationRequest）を作成します。
  3. Google サーバーが呼び出し APK を Google UI（アプリ）に送信し、認証をリクエストします。
  4. Google UI がユーザー情報を決済インテグレーター APK（AUTHENTICATE_V1(authReq)）に送信します。
  5. 決済インテグレータ APK が、リクエスト（authReq）を決済インテグレータのサーバーに送信します。
  6. 決済インテグレータ サーバーは、チャレンジを決済インテグレータ APK に返します。
  7. 決済インテグレータ APK がユーザーにチャレンジを返信します。
  8. ユーザーが本人確認書類を提出します。この書類は決済インテグレーター APK に送信されます。
  9. この証明は決済インテグレータ サーバーに送信されます。
  10. サーバーが、署名付きの authenticationResponse を作成します。
  11. 認証レスポンスに成功し、authResp メッセージが決済インテグレーター APK に送信されます。
  12. 成功メッセージ（authResp）が決済インテグレータ APK から Google UI に送信されます。
  13. Google UI が Google サーバーにレスポンスを送信します。
  14. Google サーバーは成功のレスポンスを解釈します。

SMS-MT OTP 認証

別の認証方法として、ショート メッセージ サービス、モバイル終端、ワンタイム パスワード（SMS-MT OTP）があります。このメカニズムでは、ユーザーの電話番号を利用して、認証用のワンタイム パスワードをユーザーに送信します。Google はインテグレータに、ユーザーの電話番号に OTP を送信するよう求めます。ユーザーがその OTP を受信して Google のインターフェースに入力した後、ユーザーは認証されます。

このフローには次の手順が含まれます。

  1. Google のユーザー インターフェース（UI）で、すでにインテグレータに登録されている電話番号の入力を求めるメッセージがユーザーに表示されます。
  2. ユーザーが Google UI で電話番号を入力する。
  3. Google がインテグレータをトリガーして（sendOtp メソッドを呼び出し）、ユーザーにワンタイム パスワード（OTP）を送信します。
  4. ユーザーは OTP を含む SMS メッセージを受信します。
  5. ユーザーは受け取った OTP（capture、associateAccount、verifyOtp の入力として使用）を Google のインターフェースに入力し、ユーザーを認証します。これは認証の証明です。

スタンドアロン モードでは、verifyOtp メソッドのみが OTP 値の確認のために呼び出されます。

次のシーケンス図は、OTP 送信時のユーザーの電話、Google、インテグレータ間のやり取りを示しています。

電話（OTP の送信）の認証フロー

電話（OTP）認証フロー

次の図に、オブジェクトのリストとそれぞれのオブジェクトを示します。

  • ユーザー: Google アカウントにお支払い方法を追加するユーザーです。
  • Google UI: お客様がお支払い方法の設定を開始する Google のウェブサイトまたはスマートフォン アプリ。 注: Google UI が電話アプリの場合は、スマートフォンはすでにユーザーの電話番号を認識しているため、最初のいくつかのステップはスキップされます。
  • Google サーバー: 認証チェックとその他の認証タスクを行う Google のバックエンド サーバー。
  • 決済インテグレータ サーバー: ユーザーの情報が保存されているインテグレータのバックエンド サーバー。

これは OTP 認証フローであるため、ユーザーが Google のスマートフォン アプリまたはウェブサイト（Google UI）を使用してお支払い方法を追加しようとしていると想定します。ここから初期化を開始します。

  1. Google の UI（電話またはウェブサイト）に電話番号の入力を求められる。
  2. ユーザーが Google UI に電話番号を入力する。
  3. Google UI が番号（sendChallenge(phoneNum)）を Google サーバーに送信します。
  4. Google サーバーが決済インテグレーター サーバー（SendOtp(phoneNum)）にワンタイム パスワードを送信するリクエストを送信します。
  5. 決済インテグレータ サーバーは、ワンタイム パスワード（OTP）をユーザーに送信します。
  6. 決済インテグレータ サーバーは、#5 で Google のリクエストに応答し、OTP が正常に送信されたことを通知します。
  7. ユーザーが Google UI（電話またはウェブサイト）にこの OTP を入力します。
  8. Google の UI から Google サーバーに OTP が送信され、最終的には確認のために決済インテグレータに送信されます。これにより、ユーザーの本人確認と認証が行われます。

認証と再認証

認証が行われる可能性がある時点は次の 2 つです。

  1. 初期認証 - ユーザーの識別と認証に使用されます。初期認証は associateAccount メソッドへの入力として使用されます。
  2. 再認証 - スタンドアロンや capture への入力など、他のすべてのコンテキストで使用されます。

再認証は初期認証とは異なります。単に再認証を行うことでユーザーの再識別を望みません。再認証は、ユーザーに特定のアカウントを所有していることを証明するためのもので、Google の裁量により行われます。

このプロセスでは、associationId と呼ばれる参照が、（関連付けフローから）元の関連付けに提供されます。これは、関連付けフローで associateAccount メソッドを呼び出すことで提供されます。associationId は、チャレンジ対象のアカウントを識別します。セキュリティ上の理由から、ユーザーは本人確認が行われているアカウントを変更できません。

SMS-MT OTP 再認証の場合、Google は、sendOtp への最初の通話で提供された電話番号を固定番号として保持します。セキュリティ上の理由により、これは変更できません。

以下は、購入前に Google が本人確認（再認証）を決定するフローの例です。

再認証フロー

再認証フロー

オブジェクトのリストとそれぞれが表すものは次のとおりです。

  • ユーザー: 購入を希望するユーザーです。
  • Google UI: お客様が購入を開始した Google のウェブサイトまたはスマートフォン アプリ。
  • 決済インテグレータ UI: ユーザーがインテグレータのアカウント情報にアクセスできる顧客向けのウェブサイトやアプリ。
  • Google サーバー: 再認証チェックやその他のタスクを行う Google のバックエンド サーバー。
  • 決済インテグレータ サーバー: ユーザーの情報が保存されているインテグレータのバックエンド サーバー。

お客様が購入を開始すると再認証フローが開始されます。これにより、ユーザーを再認証するフローが初期化されます。

  1. ユーザーが商品やサービスを購入することに決めました。
  2. リクエストは Google UI から Google サーバーに送信されます。
  3. Google サーバーが Google UI に認証リクエスト（authenticationRequest）を返します。
  4. Google UI が、ユーザーを認証（associationId、authenticationRequest）するためのリクエストを決済インテグレーター UI に送信します。
  5. 決済インテグレータ UI は、本人確認を行うためにユーザーを検索します（LookupIdentity（associationId））。
  6. 決済インテグレータ UI は、UI（インテグレータのウェブサイトまたはアプリ）でユーザーに認証情報の入力を求めます。
  7. 認証レスポンスが決済インテグレータ サーバーに送信されます。
  8. 署名付き認証レスポンス（authenticationResponse）が決済インテグレーター UI に返されます。
  9. 認証レスポンス（authenticationResponse）は決済インテグレータ UI から Google UI に送信されます。
  10. Google UI が、購入情報を含むレスポンスを Google のサーバーに送信します。
  11. Google のサーバーは、（利用可能な資金を見つけるために）capture メッセージを決済インテグレータ サーバー（authenticationRequestId、GPT、金額）に送信します。
  12. 決済インテグレータ サーバーは、成功のメッセージを Google サーバーに送り返します。
  13. Google のサーバーが成功のメッセージを Google UI に送信します。
  14. Google の UI によって、お客様に商品が配送されます（または、まもなく配送されることが通知されます）。

SMS-MO 認証

ショート メッセージ サービスのモバイル発信認証フローでは、ユーザーのスマートフォンから決済インテグレータに送信される認証リクエスト ID を含む SMS を利用してユーザーを認証します。

SMS-MO 認証フロー

次の図に、オブジェクトのリストとそれぞれのオブジェクトを示します。

  • ユーザー: Google アカウントにお支払い方法を追加するユーザーです。
  • Google の UI/デバイス: お客様がお支払い方法の設定を開始する Google のスマートフォン アプリ。
  • Google サーバー: Google のバックエンド サーバー。ARID（認証リクエスト ID）を使用して SMS の手順を生成し、インテグレータから認証結果を受け取ります。
  • 決済インテグレータ サーバー: 認証 SMS を受信し、認証リクエスト ID を Google に返すインテグレータのバックエンド サーバー。

これは認証フローであるため、すでにユーザーがアプリ（Google UI）を使用して、お支払い方法を追加しようとしていると仮定します。ここから初期化を開始します。

  1. ユーザーは、追加するトークン化された支払い方法を選択します。
  2. Google UI が Google サーバーを呼び出して SMS-MO チャレンジを開始します。
  3. Google サーバーから SMS 手順が返されます。SMS の手順は、送信先と、認証リクエスト ID を含む本文で構成されます。
  4. Google UI が SMS を決済インテグレータに送信します。
  5. 決済インテグレータ サーバーは、認証リクエスト ID を使用して Google サーバーの authenticationResultNotification エンドポイントを呼び出します。
  6. Google サーバーは認証リクエスト ID を検証し、サーバーは SUCCESS を返します。
  7. Google UI は Google サーバーを呼び出して、認証の試行結果を取得します。
  8. Google サーバーのレスポンスは SUCCESS です。

SMS-MO 認証のシミュレーション

SMS-MO 認証フローの診断テストを実行するために、Google では SMS シミュレート エンドポイントを定義しています。これにより、サンドボックス環境で関連付けのテストを実行するときに、実際の SMS を送信して検証する必要がなくなります。

シミュレートされた SMS-MO 認証フロー

次の図に、オブジェクトのリストとそれぞれのオブジェクトを示します。

  • テスター: SMS-MO 関連付け診断テストを開始するユーザー。
  • Google UI: テスターが開始し、SMS-MO 診断テストのステータスをモニタリングする Google の UI。
  • Google サーバー: Google のバックエンド サーバー。認証リクエスト ID（ARID）を使用して SMS の手順を生成し、シミュレーションされた SMS メッセージを送信して、インテグレータから認証結果を受け取ります。
  • 決済インテグレータ サーバー: シミュレートされた認証 SMS を受信し、認証リクエスト ID を Google に返すインテグレータのバックエンド サーバー。

このフローの手順は次のとおりです。

  1. テスターは、テストに使用するテスト登録者 ID（SID）を提供することで、SMS-MO 診断テストを開始します。この SID は、決済インテグレータへの simulateSms 呼び出しに含まれます。
  2. Google UI が Google サーバーを呼び出して SMS-MO チャレンジを開始します。
  3. Google サーバーから SMS 手順が返されます。SMS の手順は、送信先と、認証リクエスト ID を含む本文で構成されます。このテストでは、宛先は決済インテグレータのサンドボックス HTTPS 接続によってオーバーライドされます。
  4. Google UI が Google サーバーを呼び出して、シミュレートされた SMS メッセージを送信します。
  5. simulateSms 呼び出しは、Google サーバーから決済インテグレータ サーバーに対して行われます。認証リクエスト ID とサブスクライバー ID（ステップ 1 で指定）の両方が API 呼び出しに含まれています。
  6. 決済インテグレータ サーバーは ACKNOWLEDGED を返します。
  7. Google サーバーは Google UI に SUCCESS を返します。
  8. 決済インテグレータ サーバーは、認証リクエスト ID を使用して Google サーバーの authenticationResultNotification エンドポイントを呼び出します。
  9. Google サーバーは SUCCESS を返します。
  10. Google UI は Google サーバーを呼び出して、認証の試行結果を取得します。
  11. Google サーバーは「COMPLETED」を返します。
  12. Google UI が Google サーバーを呼び出して関連付けの試行を実行します。
  13. associateAccount 呼び出しは、Google サーバーから決済インテグレータ サーバーに対して行われます。
  14. 決済インテグレータ サーバーは SUCCESS を返します。
  15. Google サーバーは SUCCESS を返します。
  16. Google UI が更新され、SMS-MO 診断テストが正常に完了したことがテスターに表示されます。

ベスト プラクティスとその他の考慮事項

プラットフォームの選択

モバイルアプリと PC ウェブ向けの認証フローを用意することで、インテグレータはできるだけ多くのユーザーにリーチできる。Android アプリは優れたユーザー エクスペリエンスを提供し、コンバージョン率も高いため、Google はインテグレータにその Android アプリをサポートすることを強くおすすめします。ウェブと Android アプリケーションの認証 API で渡されるパラメータは同じです。