2要素認証の運用ニーズに対してTwilio Verifyサービスをご提案可能です!
読む所要時間: 15 分
Twilio Verifyは、ワンタイムパスコード(OTP)をSMS/電話/メール/プッシュ/TOTP(Time-based One-Time Password)を介して送信・検証し、ユーザーID認証を行う専用ソリューションです。企業が独自のOTPソリューションを構築する際に、Twilioが提供するProgrammable Messaging APIを、その基盤部分で利用できますが、社内でOTPソリューションを維持管理することは複雑で、多くのリソースを必要とします。特に、メッセージングの市況やコンプライアンス要件が変化し続ける中では、その複雑性はなおさらです。こういった中、多くの企業がTwilio Verifyに移行している背景として、Programmable Messagingと変わらないグローバルな信頼性や、圧倒的な大規模配信性に加えて、以下のような利点があるものと考えています。
- 規制やコンプライアンス管理: 例 - 米国のA2P 10DLC (application-to-person 10 digit long codeの略)
- Twilio Verifyの一環として確保済みの送信電話番号プールがサービスに含まれていること (ショートコード、ロングコード、フリーダイヤル、グローバルな英数字の送信者ID*など)
- Twilio Verifyの一環として最適化されたワールドワイドな配信 (送信元種別やコンプライアンスなどへの選択・配慮がグローバル規模で行えていること)
- トークンの生成(/送信)と検証を処理するステートレスAPI (オプションで独自コードを組み込む bring-your-own code の選択肢も可能)
- テンプレート化されたOTPメッセージの翻訳: 数十か国語対応
- マルチチャネルをサポート: SMS、電話、メール、プッシュ、TOTP
このガイドでは、Verify APIの紹介と、アプリケーションをProgrammable SMSからTwilio Verifyに移行するためのガイドラインを提供します。
*国により英数字の送信者IDのご利用には事前登録が必要です。詳しくはこちらをご確認ください。
Verifyによるトークン(生成/)送信を行うための移行要件
移行プロセスでは、最初にVerifyを利用するための1回限りの初期セットアップを行い、その後、Programmable SMSで利用していたAPIコール部分を1ヶ所Verify APIコールに置き換える必要があります。OTPのユーザー体験部分のコードロジックが既にある場合、製品のデザインは再利用できます。また、それなりの量の(不要)コード(部分)を削除することになります。いずれも歓迎できることだと思います。
Programmable SMSでは、最低限、以下のことを行う必要があります。
- 電話番号を購入する
- ランダムな数字のコードを生成する
- データベースにコードを保存し、送信先エンドユーザーと関連付ける
- コードをSMSで送信する
- コードを検証する
Verifyでは、1/2/3の手順を実施する必要はありません。代わりに、以下を行う必要があります。
- Verifyサービスを作成する(セットアップは初回1回限り)
- コードをSMSで送信する
- コードを検証する
以下、OTPの送信に必要なProgrammable SMSのコード例を示します。
同じコードのVerifyバージョン(以下)では、次の処理は不要です。
from
番号- トークン生成
storeToken
関数
Verifyサービス
Verifyでは構成にサービスを使用します。Verify APIリクエストを送信するには、Twilioの資格情報とVerifyサービスSIDの両方が必要です。サービスの作成やアップデートは、次の2通りの方法で行うことができます。
- Verify APIを使用する
- コンソール上のVerifyのセクションで行う
サービス設定の一例として、名前の編集(メッセージテンプレート上に表示される)、コード長(4~10文字)の設定、警告 “Do not Share Warning” (“共有しないでください”) などの有/無効設定などを行えます。
独自のカスタムコードの組み込み
トークンコード生成についてはTwilio Verify内蔵版の利用をお勧めしますが、独自ロジックの使用も、上記APIコール上で customCode
パラメータを指定することにより、いつでも対応可能です。カスタマイズのオプションをご確認いただき、サポート部門までご連絡いただければ、この機能を有効にいたします。カスタム認証コードをご使用の場合は、ユーザーがコードを検証したかどうか、Twilioにもフィードバックをお戻しください。生成/送信したトークンコードに対して、コード検証結果をしっかりと関連付けることにより、弊社側でグローバルなルーティングを積極監視を正しく行い、適切に運用継続することができます。
検証メッセージのローカライズ
Verify APIは、日本語を含む何十もの各国語でのローカリゼーションと翻訳を行います。デフォルトの言語の設定方法やローカライズされたメッセージの送信方法については、ドキュメントをご確認ください。
Verifyによるトークン検証を行うための移行要件
トークンの検証は難しいことではなく、Verify APIを使えば保存されているトークンをストレージから取得する作業などが不要となります。
Programmable SMSでは、トークンの検証は次のようになります。
Verifyではトークン検証向けにもう一つのAPIコールが必要ですが、トークンを保存したり取り出したりする必要はありません。
エラー処理
Verifyのエラーコードは、Programmable SMSのエラーコードとは異なります。そのため詳細をドキュメントでご確認ください。以下は一般的なエラーの例です。
- Error 60200 - Invalid parameter : たとえば、電話番号が無効である場合が挙げられます。
- Error 60203 - Max send attempts reached : ブログ記事 “レートリミットなしでTwilio Verifyをテストする方法” (英語)をご確認ください。
E.164形式の電話番号の厳格運用
Verifyでは、+15552317654
などのE.164形式の電話番号で検証を開始します。Programmable SMSは、電話番号のパラメータに寛容なため、スペースなどが許容されていました。E.164形式で番号操作する例については、Lookup API、こちらのブログ記事を参照してください。
ベストプラクティス
Lookup APIを使用して電話番号をE.164形式に変換する
Twilio LookupのAPIコール(無料)を行うことにより、2つの有用な情報を得ることができます。
- E.164形式の電話番号 : 継続中の検証のために必要な形式です。
- ISO 3166 alpha-2 形式の国コード(
US
,CA
,BR
,JP
など) : 国の許可リストまたはブロックリストを作成する際に活用できます。
今後の使用に備え、E.164形式の電話番号と国コードの両方をデータベースに保存しておいてください。詳しくは、Lookupのドキュメントをご確認ください。
検証対象ユーザを特定の国に制限する
グローバルなユーザーがいるサービスを展開している場合、すべての国のユーザからのリクエストを受け入れる運用もあります。一方、一部の国からのトラフィックのみを想定している場合、許可リストを作成することで、通信料金詐欺の課題に対処することができます。逆に、トラフィックを期待していない国からのリクエストについて、ブロックリストを作成しておき対処することもできます。
FAQ
Verifyを使用して新しい検証リクエストをしても、同じコードが表示されるのはなぜですか?
Verifyトークンは10分間有効なため、その間はパスコードが変更されません。強制的に新しいパスコードを設定するには、検証のライフサイクルを完了させてください。
Verifyのレートリミットは別枠となりますか?
Verify SMSのレートリミットは以下の通りです。
レートリミットの詳細については営業またはサポートまでお問い合わせください。大半のお客様は、Verifyのデフォルトのレートリミットで十分だとお考えですが、サービスレートリミットを追加設定することにより、アプリケーションを保護することもできます。
どうすればレートリミットを受けずにVerifyをテストできますか?
ブログ記事 “レートリミットなしでTwilio Verifyをテストする方法” (英語)をご確認ください。
Verifyの料金について教えてください。
Verifyの検証ベースの料金は、検証1回につき0.05ドルです。Verifyにはグローバルな電話番号のコストが含まれていることにご留意ください。詳しくは、Verifyの料金ページを、ボリュームディスカウントについてはご相談ください。