Twilio AuthyからVerifyへの移行 (SMSベースの二要素認証のケース)
読む所要時間: 16 分
Twilio Verify API は、Authy API を進化させたもので、SMS、音声通話、Eメールによるワンタイム・パスコード (OTP) の送信・検証を引き続きサポートし、開発者の使い勝手を向上させ、さらに新機能を追加しています。Authy APIは今後もサポートされますが、主要な機能強化はVerify APIを対象に行われることにご留意ください。
Verify APIの特徴を以下に記載いたします。
- JavaScript、Java、C#、Python、Ruby、PHPのTwilioヘルパーライブラリ
- モバイルアプリに埋め込み可能なプッシュ認証用SDK
- カスタマイズ可能なレートリミット
- コードの送信や検証等に関する可視性と知見の提供
- 今後の機能強化が期待できます!(例: WhatsAppチャネルへの対応)
このガイドでは、Verify APIの紹介と、皆さまがメンテナンスされているID認証アプリケーションをAuthyからVerifyに移行するためのガイドラインを説明します。
Twilio VerifyのベースAPI
Verifyは、TwilioのAPIにホストされるようになりました。新しいベースURLは以下となります。(参考: 従来のAuthy APIでは “https://api.authy.com” でした。)
認証にTwilioアカウントの資格情報を使用する
Authy APIでは、Authy API Keyが必要でした。Verify (v2) APIでは、以下のリクエストのように、Twilioコンソールに表示されるTwilio資格情報を使用します。
Twilioヘルパーライブラリを含む充実の開発者ツール
Authyのヘルパーライブラリはもう必要ありません。Verify APIではTwilioのヘルパーライブラリを利用することが可能で、C#、Java、PHP、Python、Ruby、Node.js、Golang [パイロットリリース] といったライブラリを公式にサポートしています。
Verifyは、TwilioのCLIやOpenAPI仕様 [ブログ記事] のスコープでもあります。詳細についてはAPIリファレンスをご確認ください。
移行の例
SMSで二要素認証を実現するアプリケーションをAuthyからVerifyに移行する際のコード例については、以下のコード差分をご確認ください。
AuthyのApplicationsはVerifyのServicesに対応します
Verifyは設定や構成に ‘Service’ を使用します。対してAuthy APIでは ‘Application’ を作成し、そのAPIキーを使って検証処理を管理していました。Verifyでは、Twilioの資格情報とService SIDの両方が必要です。Serviceの作成と更新には2つの方法があります。
- Verify APIを利用
- TwilioコンソールのVerifyの画面を活用
ApplicationはAuthyと初期のVerifyとで共有されていたので、Verifyのコンソールに ‘Application’ が表示されているかもしれません。Serviceは、設定や構成のための新しい方法であり、Verify (v2; 現行最新) を始めるためには、[Service]タブの中で操作・作業する必要があります。
コード検証のライフサイクルに関する可視性や知見
新しいVerify APIでのみ利用可能で、テレフォニー配信状況を含むコード検証状況をコンソールで確認することができます。
エラー処理
VerifyのエラーコードはAuthyのエラーコードとは異なります。詳細はドキュメントをご確認ください。よくあるエラーは以下の通りです。
- Error 60200 - Invalid parameter. 例えば、無効な電話番号などです。
- Error 60203 - Max send attempts reached. レートリミットに関するエラーです。併せてブログ記事「How to test Twilio Verify without getting rate limited」をご確認ください。
Authy IDの役割はVerifyではE.164 形式の電話番号です
Authy IDは、Authy APIで検証コードをSMS送信する際のパラメータとして使用されていました。
Verifyでは、+15552345678
のようなE.164形式の電話番号で検証を開始します。各国の形式の電話番号をE.164形式に変換する例については、Lookup APIをご確認ください。
移行のためのベストプラクティス
Lookupを使用して電話番号をE.164形式に変換する
LookupフォーマットのAPI実行(無料)で、2つの有用な情報が得られます。
- E.164形式の電話番号です。以降の検証のために必要となります。
- ISO 3166 alpha-2形式の国コード(例:
US
、CA
、BR
)。アプリケーションのロジックとして国レベルの許可リストまたはブロックリストを作成する必要がある場合に有用です。
E.164形式の電話番号と国コードの両方をデータベースに保存し、今後の使用に備えます。
詳しくは、Lookupのドキュメントをご確認ください。
国レベルの許可リストを定義する
世界中にユーザーがいる場合は、例えばすべての国からの検証リクエストを許可することができます。また、一部の国からのリクエストのみを想定する場合は、許可リストを作成することで、料金詐欺を軽減することができます。逆に、リクエストを期待していない国がある場合は、ブロックリストを作成することもできます。
アプリケーションからAuthyユーザーを削除する
あるユーザーの移行準備が整った後は、移行元アプリケーションからAuthyユーザーを削除することをお勧めします。Authyユーザーを削除する方法は、ドキュメントをご確認ください。
FAQ(よくある質問)
Authy IDだけを保存していて、ユーザーの電話番号を持っていない場合は?
個人情報保護の観点から、ユーザーの電話番号をAPI上お知らせすることはできません(ユーザーはAuthyアプリで電話番号を変更することができますので、ユーザー登録時に最初に提供された電話番号とは異なる電話番号が保存されている可能性があります)。
その代わりに、移行プロセスの中でユーザーに電話番号の「確認」を促すことをお勧めします。ご負担を減らすために、多くのお客様はこの確認ステップを完了するために30日間の猶予期間を設けています。具体的には、Authy User Status API エンドポイントを使用して、ユーザーの電話番号の下4桁を取得し、確認を促すことができます。
以上を踏まえ、以下が推奨手順となります。
- 入力された番号のLookup(参照)を行う: これにより、番号や回線の種類を確認することができます。例えば、固定電話の番号の場合には音声通話によるコード検証処理を優先するよう優先設定したり、あるいはエラーを出して携帯電話の番号を要求したりすることができます。
- 初回の電話認証を行う: Verify APIを使用して、電話番号にワンタイムパスコード(OTP)を送信し、ユーザーが本当にその番号を所持していることを確認します。
- 確認後、電話番号をデータベースに追加する: 今後コードを送信する際には、この電話番号が必要になります。
- Authyユーザーを削除する: Authyアプリケーションからユーザーを削除し、移行作業を完了します。
ユーザーが30日(または任意の期間)以内に電話番号を確認しない場合は、そのユーザーに関するAuthy APIベースの検証ロジックを廃止し、二要素認証処理そのものに再登録してもらうことができます。
ご不明な点がございましたら、お気軽にお問い合わせください。
Verifyを使って新しい認証リクエストをすると、同じコードが表示されるのはなぜですか?
Verifyのトークンは10分間有効で、その間はパスコードは変更されません。強制的に新しいパスコードにするには、検証のライフサイクルを完了させるか、検証をキャンセルしてください。
VerifyのレートリミットはAuthyと違いますか?
Authyと比べてVerifyのレートリミットには微妙な違いがあります。
VerifyのSMSのレートリミットには以下があることに留意ください。
レートリミットの詳細については、営業またはサポートにお問い合わせください。ほとんどのお客様は、Verifyのデフォルトのレートリミットで十分だと思われますが、追加のサービスレートリミットでお客様のアプリケーションを保護することもできます。
レートリミットを受けずにVerifyをテストするには?
ブログ記事「How to test Twilio Verify without getting rate limited」をご確認ください。
VerifyはTOTPをサポートしていますか?
はい、TOTPのサポートはパイロットリリースを開始したところです。パイロットリリースの検討やTOTPサポートの詳細についてはお問い合わせください。[TOTP: Timed One Time Passcode]
Verifyにはレポート用のAPIがありますか?
VerifyのList Attempts APIをご検討ください。パイロットリリースを開始したところで、詳細についてはお問い合わせください。