
シェア:
スタンダップ・コメディーの学位論文を持つ俳優の訓練を受け、ミートアップ・シーンを経てPHP開発に携わるようになった。技術について話したり書いたり、レコード・コレクションから変わったレコードを再生したり買ったりしています。
Vonage Verify V2が2FA統合のためのGAになりました。
所要時間:1 分
二要素認証(2FA)のAPIであるVerifyのバージョン2がリリースされました!私たちの2FAソリューションのこの進化は、非同期統合にWebhooksを使用し、より多くのオプションと柔軟性を提供することによって、開発者にとってより良く機能するように設計されています。V1とV2の違いを見ていきましょう。また このページのドキュメント.
さようならポーリング、こんにちはウェブフック
Verifyのバージョン1は、より同期的なフローを持つように設計されている。この例としては、リクエストを開始した後、ユーザーがPINコードを送信する前にリクエストのステータスを知る必要がある場合、APIをポーリングする必要がある(これは事実上、リクエストライフサイクルの「開始」と「終了」としてカウントされる)。
Verifyの最初の反復は、同期フローを中心に構築されており、リクエストの開始後、ユーザーのPINコードを送信する前に、リクエストのステータスをチェックするためにAPIポーリングが必要であった。
対照的に、Verify Version 2はWebhooksの力を利用しています。リクエストを開始すると、一意の GUID が提供される。JWT があなたの認証方法であると仮定すると、あなたの統合は、更新のための GUID リクエストに対応する着信 Webhook をリッスンします。これらのウェブフックに関連するエンドポイントは次のとおりです:
リクエストを開始する
ユーザーのPINをVerifyする。
リクエストをキャンセルする
不正防止の強化
通信APIを悪用した詐欺行為が急増しているため、弊社は Verify不正防止システムをバージョン2に統合しました。このシステムは、疑わしい活動を検出し、ネットワークブロックをトリガーします。さらに柔軟性を高めるため、ユーザーは この機能をカスタマイズをカスタマイズすることもできます。
強化された配達方法
APIに加えた最も大きな変更は、新しい通信チャネルのオプションを追加したことです。新しいリクエストを開始する際には、以下の既存のメソッドを使用できます:
SMS
音声合成(TTS)
これらの新しい方法を使うことができる:
WhatsApp
電子メール
サイレント認証
私は、製品の拡張を...200%!
ワークフロー制御の強化
新しいチャンネルに関連して、リクエストのワークフローをどのように構成するかを正確にコントロールできるようになりました。以前は workflow_idをリクエストに送信していました。 を送信していました。.その代わりに、V2では、ワークフローにカスタムペイロードを含めることができます。例えば、Silent Auth -> Email -> SMS の順番でチャネルを送信したい場合、リクエストは以下のようになります:
{
"brand": "ACME, Inc",
"workflow": [
{
"channel": "silent_auth",
"to": "44770090000X"
},
{
"channel": "email",
"to": "alice@company.com",
"from": "bob@company.com"
},
{
"channel": "sms",
"to": "44770090000X"
}
]
} カスタムPIN生成
開発者はカスタムコードを必要とするチャンネル(WhatsApp Interactiveとサイレント認証以外)にカスタムコードを送信することもできます。このコードは4~10文字の英数字です。以下は独自に生成したPINを使用した場合に送信されるJSONペイロードの例です:
{
"brand": "ACME, Inc",
"code" : "R4Fe4dR1Qz",
"workflow": [
{
"channel": "sms",
"to": "447700900000"
}
]
} もっとRESTを
Verifyのバージョン2では、HTTPレスポンス・コードをよりうまく使えるようになっている。そう、そう、そう、OK:だからRESTではなく(見出しに入れたかっただけ)、HTTPプロトコルのより良い使い方だ。いくつか例を挙げよう:
すでに実行されたリクエストを開始する場合、次のようなメッセージが表示されます。 409レスポンスを返す。
レートリミットを超えると、標準レートが適用される。 429
リクエスト開始エンドポイントまたはPIN送信エンドポイントのいずれかに無効なペイロードがあると、次のようになります。 422
何度も不正な暗証番号を送信すると、最終的には 410を受け取ることになります。
あなたは何を作る?
我々が立ち上げた新しいチャンネルは、開発者に、彼らのシステム、サイドプロジェクト、企業アプリケーションに2FAを統合する豊富な選択肢を与える。問題は、あなたが何を作ったか?情熱的なサイドプロジェクトからスタートアップになった Laravelそれとも Rails?Nodeのマイクロサービス・アーキテクチャで構築された企業全体のロールアウト?私たちはそれを知りたいのです! コミュニティのSlackにアクセスしてください。