非同期実装

はじめに

非同期実装は 同期 デバイスクライアントを使用して一連の呼び出しを行う代わりに、ワークフローのすべての部分を ウェブフック・コールバック あなたが定義したURLに送信される。

このガイドでは、非同期アプローチを使用してサイレント認証を実装する方法を説明します。 バックエンドは、認証結果を受け取るコールバックを設定します。

VonageApp BackendMobile AppVonageApp BackendMobile AppTrigger VerificationOpen check_url over cellular network using Vonage SDKCheck Verification CodeVerify phone numberPOST v2/verifyWebhook 202 OK (check_url, request_id) / ErrorResponse (check_url)GET check_urlSeveral 302 RedirectsHTTP 200 (request_id, code)Request (request_id, code)POST v2/verify/:request_id (code)HTTP 200 (status: completed)Response (Completed)

アプリケーションの作成

まず、次のページにアクセスする。 開発者ダッシュボード でアプリケーションを作成します:

  • Capabilities」でVerifyが有効になっていることを確認する。
  • コールバックイベントを受信するように Status URL を設定します。
  • を生成する。 JWT アプリケーションのアプリケーションIDと秘密鍵を使用する。

トリガー検証

サイレント認証プロセスを開始するには、以下のリクエストを行う。 /verify.次の例では ワークフロー は、Verify が最初にサイレント認証を使用しようとすることを指定します。要求が何らかの理由で失敗した場合、SMS にフォールバックし、音声通話 OTP に続く。

サンプルを実行するには、サンプルコード内の以下の変数を独自の値に置き換えてください:

可変 説明
JWT を使用して API リクエストを認証します。 JWT.
VERIFY_BRAND_NAME 認証メッセージでユーザーに表示される会社名またはサービス名。
VONAGE_APPLICATION_PRIVATE_KEY_PATH アプリケーションの秘密鍵へのパス。
VONAGE_APPLICATION_ID アプリケーションのアプリケーションID。
VERIFY_NUMBER E.164形式のOTP送信先電話番号(例. +441112233447).

Write the code

Add the following to request.sh:

curl -X POST "https://api.nexmo.com/v2/verify" \
  -H "Authorization: Bearer $JWT"\
  -H 'Content-Type: application/json' \
  -d $'{
	 "brand": "'$VERIFY_BRAND_NAME'",
   "workflow": [
      {
         "channel": "silent_auth",
         "to": "'$VERIFY_NUMBER'"
      },
      {
         "channel": "sms",
         "to": "'$VERIFY_NUMBER'"
      },
      {
         "channel": "voice",
         "to": "'$VERIFY_NUMBER'"
      }
   ]
}'

View full source

Run your code

Save this file to your machine and run it:

sh request.sh

応答

リクエストが成功した場合、レスポンスは以下を返す。 HTTP 200 を持つ。 check_url これは次のステップで必要になる:

HTTP/1.1 200 Ok 
{
  "request_id": "470b478f-334c-4f6f-b90d-b44e77ed24bf",
  "check_url": "https://api-eu-4.vonage.com/v2/verify/470b478f-334c-4f6f-aaab-b4a342aed24bf/silent-auth/redirect"
}

電話番号の書式が正しくないなど、リクエストにエラーがある場合、レスポンスには HTTP 422 このようなエラーだ:

HTTP/1.1 422 Unprocessable Entity 
{
  "title": "Invalid params",
  "detail": "The value of one or more parameters is invalid",
  "instance": "b30db5a7-338e-402e-aa5a-40073a9aa07c",
  "type": "https://developer.vonage.com/en/api-errors#invalid-params",
  "invalid_parameters": [
    {
      "name": "workflow[0]",
      "reason": "`to` Phone number is invalid"
    }
  ]
}

非同期実装を使用しているので、APIレスポンスと並行して コールバック (またはWebhook)をダッシュボードアプリケーションの設定で指定されたURLに送信し、リクエストの進行状況を通知します。

へのAPI呼び出し中に /verifyの場合、Verify APIは内部的な事前チェックを行う。問題がなければ、コールバックは以下のようなボディを持つ:

HTTP/1.1 200 Ok 
{
  "request_id": "21a425df-04b2-43f2-990e-b19ee22e18a0",
  "triggered_at": "2025-07-14T17:01:47.032Z",
  "channel": "silent_auth",
  "status": "action_pending",
  "action": {
    "type": "check",
    "check_url": "https://api-eu-4.vonage.com/v2/verify/21a425df-04b2-43f2-990e-b19ee22e18a0/silent-auth/redirect"
  },
  "type": "event"
}

リクエストが期限切れになるか、キャンセルされるまで、 check_url によるサイレント認証チェックに使用される。 認証URLの送信.このコールバックを受け取ったら、次のように

GET
リクエストをしなければならない。 check_url 認証しようとしているモバイル・デバイスから。

重要だ: について check_url リクエストは(Wi-Fiではなく)モバイルデータ接続を介して実行する必要があります。これを確実にするために推奨される方法は、デバイスのセルラーネットワークを介してリクエストを自動的にルーティングするVonage Client SDK(iOSまたはAndroid)を使用することです。詳しくは サイレント認証のためのWi-Fiバイパスガイド をご覧ください。

これらの事前チェックのいずれかが、例えばネットワークエラーやサポートされていないオペレーターのために失敗した場合、コールバックは次のようになる:

HTTP/1.1 200 Ok 
{
  request_id: "470b478f-334c-4f6f-b90d-b44e77ed24bf",
  triggered_at: "2025-07-14T16:53:16.965Z",
  channel: "silent_auth",
  status: "failed",
  type: "event"
}

もし /verify リクエストにフォールバックチャネルが含まれている場合、Verifyは以下のシーケンス図に示すように、そのチャネルの使用を継続する:

VonageApp BackendMobile AppVonageApp BackendMobile AppTrigger VerificationVerify phone numberPOST v2/verifyInternal coverage checkWebhook 200 (status: failed)fallback channel

認証URLの送信

GET]リクエストを行うと、1つまたは複数の HTTP 302 リダイレクトは、ターゲット・デバイスの地域とキャリアに応じて行われる:

HTTP/1.1 302 Found
Location: https://eu.api.silentauth.com/phone_check/v0.2/checks/31eaf23d-b2db-4c42-9d1d-e847e75ab330/redirect

リダイレクトに従うと、次のいずれかになります。 HTTP 200 または HTTP 4xx のような応答が表示されるかもしれない。ネットワークに問題がある場合、次のような応答が表示されるかもしれない:

HTTP/1.1 412 Precondition Failed
Content-Type: application/json

{
  "title": "Network not supported",
  "detail": "Device number does not resolve to a supported Mobile Network Operator.",
  "instance": "78e23b55-1633-465e-9325-6abcf186dd00",
  "type": "https://developer.vonage.com/en/api-errors/verify-v2#precondition-failed"
}

潜在的なエラーコードの完全なリストは、以下のページにあります。 API仕様.

について タイムアウト管理 ベスト・プラクティス・ガイドの「ベスト・プラクティス」セクションには、このステップでネットワーク信号や通信範囲の問題などに対処するための有用な情報が記載されています。

リクエストが有効な場合は、次のメッセージが表示されます。 HTTP 200 あなたの request_id そして code:

{
  "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
  "code": "si9sfG"
}

注:安全な認証チェックを保証し、潜在的な中間者攻撃(man in middle attack)を軽減するために、オリジナルを保存する。 request_id と比較する。 request_id がレスポンスに返される。IDが一致しない場合は、サイレント認証チェックを中止しなければならない。詳細は サンプルアプリケーション を参照されたい。

検証コードの確認

エンドユーザーがコードを受け取ったら、クライアントアプリケーションは

POST
リクエストを /v2/verify/{request_id} エンドポイント {request_id} を、前の通話で受け取ったIDで入力してください。

サンプルを実行するには、サンプルコード内の以下の変数を独自の値に置き換えてください:

可変 説明
JWT を使用して API リクエストを認証します。 JWT.
VERIFY_REQUEST_ID について request_id 前のステップで受け取った。
VONAGE_APPLICATION_PRIVATE_KEY_PATH アプリケーションの秘密鍵。
VONAGE_APPLICATION_ID アプリケーションのアプリケーションID。
VERIFY_CODE エンドユーザーが受信した検証コード

Write the code

Add the following to check-verification-code.sh:

curl -X POST "https://api.nexmo.com/v2/verify/$VERIFY_REQUEST_ID" \
  -H "Authorization: Bearer $JWT"\
  -H 'Content-Type: application/json' \
  -d $'{
    "code": "'$VERIFY_CODE'"
  }'

View full source

Run your code

Save this file to your machine and run it:

sh check-verification-code.sh

注:サイレント認証ワークフローのコードは、以下の場合にのみチェックできます。 かつて.

コードが有効であれば、次のステータスのコールバックを受け取ります。 completed:

{
   "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
   "status": "completed"
}

エラーがある場合は「Invalid Code」と表示されます:

{
   "title": "Invalid Code",
   "type": "https://www.developer.vonage.com/api-errors/verify#invalid-code",
   "detail": "The code you provided does not match the expected value.",
   "instance": "bf0ca0bf927b3b52e3cb03217e1a1ddf"
}

その後、チェック結果が最終的にコールバックされます。成功した場合は、コールバックに "status": "completed":

{
    "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
    "triggered_at": "2020-01-01T14:00:00.000Z",
    "type": "event",
    "channel": "silent_auth",
    "status": "completed",
}

失敗した場合、例えばユーザーが拒否された場合、その旨が status フィールドにいる:

{
    "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
    "triggered_at": "2020-01-01T14:00:00.000Z",
    "type": "event",
    "channel": "silent_auth",
    "status": "user_rejected",
}

この時点で、サイレント認証の検証は完了です。