サイレント認証 - ベストプラクティス

SDKでWiFiをバイパスし、モバイルデータ接続を強制する

サイレント認証には、アクティブなモバイルデータ接続が必要です。リクエストがWi-Fi経由で行われた場合、エラーになります。ユーザーがWiFiを使用している場合でもリクエストが成功するように、Vonageはネイティブの iOS そして アンドロイド モバイルデータ接続を強制するSDK。

SDKを使用することで、エッジケースにおけるUXの影響を最小限に抑えることもできます:

  • 接続性チェック (例えば sdk_no_data_connectivity)を使用することで、より高速でシームレスなフェイルオーバーを実現することができます。
  • リダイレクト間のタイムアウト管理 低速のモバイルデータ環境下での待ち時間を短縮する。
  • iOS26対応 該当する市場(例えばスペイン)において。

さらに、Vonage SDKはHTTPリダイレクト(最大10)を処理し、タイムアウト(5秒、各リダイレクト後にリセット)を管理します。

フロントエンド

Verify内のサイレント認証は、ユーザーを認証するための簡単でわかりやすい方法を提示し、他のチャンネルと比較してより優れたユーザーエクスペリエンスを提供します。

新規アカウント作成ユースケースの場合、モバイルアプリケーションはエンドユーザーの電話番号を知らないため、ウェルカム画面の入力フィールドで電話番号を収集する必要があります。あるいは、すでにアカウントを持っていて、パスワードなしでログインしようとしているエンドユーザーは、すでに電話番号が保存されています。この場合、エンドユーザーにはあらかじめ入力済みのテキストフィールドが表示され、必要なアクションは「Verify」を選択することだけである。

Silent Authentication(サイレント認証)を体験している間、ユーザがそのプロセスに慣れ、認証プロセスがバックグラウンドで実行されていることを認識できるようにする。

進行中の状態

認証がバックグラウンドで実行されている間に期待値を設定するには、以下の方法を推奨する:

  • エンドユーザが、モバイルアプリケーションが認証タスクに取り組んでいることを認識で きるように、スピニングホイールまたは同様のフィードバックメカニズムを提示する。
  • あるいは、同じローディングインジケーターと追加テキストを表示した専用画面を表示する。

成功への道

Silent Authenticationが正常に完了すると、ユーザーはコードを入力する必要なく、明確な成功状態に移行する。

フォールバック・パス

サイレント認証フロー中に障害が発生した場合、ユーザがピンコードを挿入して2FAプロセスを完了できるように、アプリケーションフロントエンドを調整する必要がある。このコードは、フェイルオーバー・チャネルを介して配信される。

要約すると、下図は両方のユーザージャーニーを示している。 成功の道 (サイレント認証はバックグラウンドで完了します)と フォールバックパス (ユーザはフェイルオーバーコードを入力するよう促される)。

Silent Authentication Front-end Flow

サイレント認証におけるエラーとタイムアウトの処理

サイレント認証は、その性質上、モバイルデータ接続の欠如やネットワークの一時的な中断など、外部の状況によって影響を受ける可能性があります。スムーズなユーザーエクスペリエンスを保証するために、モバイルアプリは クライアント・ライブラリー独自のネットワークチェックやタイムアウト管理を実装するのではなく、例外処理を内蔵している。

SDKは問題が発生すると、何が問題であったかを示す特定の例外をスローします。例えば sdk_no_data_connectivityモバイルデータ接続が利用できない場合にスローされる。

モバイルデータなしでサイレント認証の開始を避ける

最高のユーザーエクスペリエンスを実現するために、モバイルデータ接続のチェックをご検討ください。 以前 サイレント認証リクエストを開始する。

デバイスにアクティブなモバイルデータ接続がない場合は、サイレント認証ステップを開始 せず、次の検証チャネル(SMS、RCS、音声など)に直接進みます。これにより、不要なリクエストの試行が回避され、全体的な検証時間が短縮されます。

注: について クライアント・ライブラリー は現在、実行中に接続性を検証している。例外(例えば sdk_no_data_connectivity) リクエストが開始された後に問題が検出された場合。参照 タイムアウトの動作 これらの実行時例外の処理方法については

タイムアウトの動作

アプリはこれらの例外をキャッチし、バックエンドに next_workflow エンドポイントを直ちに削除する。これにより、サイレント認証ワークフローが失敗したり、続行できなくなったりした場合でも、検証フローが優雅に継続される。

モバイルアプリが次のワークフローに移行するアクションを取らない場合、システムは60秒後に自動的にタイムアウトし、次のワークフローに進みます。

以下のシーケンス図は、リダイレクトがモバイルアプリによって正しく受信されない状況を示している。 check_url:

VonageApp BackendMobile AppVonageApp BackendMobile AppMobile app catches the exception thrown by client libraryVerify phone numberPOST v2/verifyWebhook 202 OK (check_url, request_id)Response (check_url)GET check_url fails due to network issuesNotify to move to the next Workflow (request_id, error)POST v2/verify/:request_id/next_workflow

推奨フロー

  1. SDK を使用して Silent Authentication リクエストを開始します。
  2. SDKが例外をスローした場合(例. sdk_no_data_connectivityを呼び出す)。 next_workflow エンドポイントである。
  3. アプリの内部タイムアウト(例えば、デフォルトの60秒前)内にレスポンスやコールバックを受け取らなかった場合、以下を呼び出す。 next_workflow も同様だ。
  4. そうでない場合は、通常の認証コールバックを待つ。

このアプローチは、待ち時間を最小限に抑え、ユーザーエクスペリエンスを向上させ、バックエンドが常にワークフローの正しいステップに進むようにします。

フェイルオーバーのシナリオ

このセクションでは、サイレント認証リクエスト中に発生する可能性のあるすべての シナリオを列挙し、最高のエンドユーザー・エクスペリエンスを確保するためのフェイルオーバー実 装についてアドバイスする。

シナリオによっては、次のチャネルへのフェイルオーバーが即座にトリガーされますが、フェイルオーバーがデフォルトのサイレント認証のタイムアウト(60秒)後にのみトリガーされる場合もあります。さまざまな障害シナリオをまとめた以下の表を参照してください:

シナリオ 故障理由 故障コード 故障の対応 即時フェイルオーバー?
1 サイレント認証エラー HTTP 409 { "title": "Silent Auth error", "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."} はい
2 MSISDNエラー HTTP 409 { "title": "MSISDN Error", "detail": "Device MSISDN does not match."} はい
3 ネットワークがサポートされていない HTTP 412 { "title": "Network not supported", "detail": "Device number does not resolve to a supported Mobile Network Operator."} はい
4 IPエラー HTTP 412 { "title": "IP Error", "detail": "IP Address does not resolve to a cellular device."} はい
5 iOS/Android SDKエラー -- sdk_no_data_connectivity, sdk_connection_error, sdk_redirect_error, sdk_error いいえ

サイレント認証課金

Silent Authentication要求が開始されると、Verifyプラットフォーム料金のエントリが1つ生成され、 Silent Authenticationの使用量を示すエントリが1つまたは2つ追加される。としてマークされたエントリが生成される。 INITIATED が請求されることはない。合計で、1 つの Silent Authentication リクエストは、最大 3 つの関連レコードを持つことができる。

テスト

Verifyサイレント認証をテストするには、次のようにします:

顧客がライブトラフィックを送信する必要がある場合は、以下の方法で携帯電話会社に登録する必要がある。 ネットワーク・レジストリ.