2要素認証の運用ニーズに対してTwilio Verifyサービスをご提案可能です!

June 03, 2021
執筆者
レビュー担当者

Blog header: Migrate from Programmable SMS to Verify JP

この記事は、デベロッパー エバンジェリストのKelley Robinsonが、こちら(英語)で執筆した記事を日本語化したものです。

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では、最低限、以下のことを行う必要があります。

  1. 電話番号を購入する
  2. ランダムな数字のコードを生成する
  3. データベースにコードを保存し、送信先エンドユーザーと関連付ける
  4. コードをSMSで送信する
  5. コードを検証する

Verifyでは、1/2/3の手順を実施する必要はありません。代わりに、以下を行う必要があります。

  1. Verifyサービスを作成する(セットアップは初回1回限り)
  2. コードをSMSで送信する
  3. コードを検証する

以下、OTPの送信に必要なProgrammable SMSのコード例を示します。

const accountSid = process.env.TWILIO_ACCOUNT_SID;
const authToken = process.env.TWILIO_AUTH_TOKEN;
const client = require("twilio")(accountSid, authToken);

const from = "YOUR TWILIO NUMBER";
const to = "+15558675310";

// generate a 6 digit token
const token = Math.floor(Math.random() * (999999 - 100000) + 100000);
const message = `Your Example App verification code is: ${token}`;

function storeToken(to, token) {
 /*
  * Required:
  *   - Store token with the user's phone number in your database
  *   - Set token expiration
  */
}

// send OTP
client.messages.create({ body: message, from, to }).then((message) => {
 storeToken(to, token);
 console.log(message.sid);
 // prompt user for token
});

同じコードのVerifyバージョン(以下)では、次の処理は不要です。

  1. from 番号
  2. トークン生成
  3. storeToken 関数
const accountSid = process.env.TWILIO_ACCOUNT_SID;
const authToken = process.env.TWILIO_AUTH_TOKEN;
const client = require("twilio")(accountSid, authToken);

const to = "+15558675310";

// send OTP
client.verify
 .services("YOUR VERIFY SERVICE SID")
 .verifications.create({ to, channel: "sms" })
 .then((verification) => {
   console.log(verification.status);
   // prompt user for token
 });

Verifyサービス

Verifyでは構成にサービスを使用します。Verify APIリクエストを送信するには、Twilioの資格情報とVerifyサービスSIDの両方が必要です。サービスの作成やアップデートは、次の2通りの方法で行うことができます。

  1. Verify APIを使用する
  2. コンソール上のVerifyのセクションで行う

サービス設定の一例として、名前の編集(メッセージテンプレート上に表示される)、コード長(4~10文字)の設定、警告 “Do not Share Warning” (“共有しないでください”) などの有/無効設定などを行えます。

独自のカスタムコードの組み込み

トークンコード生成についてはTwilio Verify内蔵版の利用をお勧めしますが、独自ロジックの使用も、上記APIコール上で customCode パラメータを指定することにより、いつでも対応可能です。カスタマイズのオプションをご確認いただき、サポート部門までご連絡いただければ、この機能を有効にいたします。カスタム認証コードをご使用の場合は、ユーザーがコードを検証したかどうか、Twilioにもフィードバックをお戻しください。生成/送信したトークンコードに対して、コード検証結果をしっかりと関連付けることにより、弊社側でグローバルなルーティングを積極監視を正しく行い、適切に運用継続することができます。

検証メッセージのローカライズ

Verify APIは、日本語を含む何十もの各国語でのローカリゼーションと翻訳を行います。デフォルトの言語の設定方法やローカライズされたメッセージの送信方法については、ドキュメントをご確認ください。

Verifyによるトークン検証を行うための移行要件

トークンの検証は難しいことではなく、Verify APIを使えば保存されているトークンをストレージから取得する作業などが不要となります。

Programmable SMSでは、トークンの検証は次のようになります。

const to = "+15558675310";
const token = "123456"; // acquired from UI

function fetchToken(to) {
 /*
  * Required:
  *   - Fetch the token stored with the user's phone number
  *   - Ensure the token is not expired
  */
}

// check OTP
const validToken = fetchToken(to);
if (token === validToken) {
 // successful
} else {
 // failed
}

Verifyではトークン検証向けにもう一つのAPIコールが必要ですが、トークンを保存したり取り出したりする必要はありません。

const accountSid = process.env.TWILIO_ACCOUNT_SID;
const authToken = process.env.TWILIO_AUTH_TOKEN;
const client = require("twilio")(accountSid, authToken);

const to = "+15558675310";
const token = "123456"; // acquired from UI

// check OTP
client.verify.services("YOUR VERIFY SERVICE SID")
 .verificationChecks
 .create({to, code: token})
 .then(check => {
   if (check.status === "approved") {
     // successful
   } else {
     // failed
   }
 });

エラー処理

Verifyのエラーコードは、Programmable SMSのエラーコードとは異なります。そのため詳細をドキュメントでご確認ください。以下は一般的なエラーの例です。

E.164形式の電話番号の厳格運用

Verifyでは、+15552317654 などのE.164形式の電話番号で検証を開始します。Programmable SMSは、電話番号のパラメータに寛容なため、スペースなどが許容されていました。E.164形式で番号操作する例については、Lookup APIこちらのブログ記事を参照してください。

ベストプラクティス

Lookup APIを使用して電話番号をE.164形式に変換する

Twilio LookupのAPIコール(無料)を行うことにより、2つの有用な情報を得ることができます。

  1. E.164形式の電話番号 : 継続中の検証のために必要な形式です。
  2. ISO 3166 alpha-2 形式の国コード(US, CA, BR, JP など) : 国の許可リストまたはブロックリストを作成する際に活用できます。

今後の使用に備え、E.164形式の電話番号と国コードの両方をデータベースに保存しておいてください。詳しくは、Lookupのドキュメントをご確認ください。

検証対象ユーザを特定の国に制限する

グローバルなユーザーがいるサービスを展開している場合、すべての国のユーザからのリクエストを受け入れる運用もあります。一方、一部の国からのトラフィックのみを想定している場合、許可リストを作成することで、通信料金詐欺の課題に対処することができます。逆に、トラフィックを期待していない国からのリクエストについて、ブロックリストを作成しておき対処することもできます。

FAQ

Verifyを使用して新しい検証リクエストをしても、同じコードが表示されるのはなぜですか?

Verifyトークンは10分間有効なため、その間はパスコードが変更されません。強制的に新しいパスコードを設定するには、検証のライフサイクルを完了させてください。

Verifyのレートリミットは別枠となりますか?

Verify SMSのレートリミットは以下の通りです。

  • 固有の電話番号1つにつき、コード送証の試行は10分間に5回 [リンク]
  • 固有の電話番号1つにつき、コード検証の試行は5回 [リンク]

レートリミットの詳細については営業またはサポートまでお問い合わせください。大半のお客様は、Verifyのデフォルトのレートリミットで十分だとお考えですが、サービスレートリミットを追加設定することにより、アプリケーションを保護することもできます。

どうすればレートリミットを受けずにVerifyをテストできますか?

ブログ記事 “レートリミットなしでTwilio Verifyをテストする方法” (英語)をご確認ください。

Verifyの料金について教えてください。

Verifyの検証ベースの料金は、検証1回につき0.05ドルです。Verifyにはグローバルな電話番号のコストが含まれていることにご留意ください。詳しくは、Verifyの料金ページを、ボリュームディスカウントについてはご相談ください。

Verifyは他にどのような検証方法に対応していますか?

VerifyはSMS、電話、メールプッシュTOTPに対応しています。