ワンタイムパスワード(OTP)のフローを実装するのに知っておきたいすべてのこと (Part 2)

# はじめに

皆さん、こんにちは。
[GetOTPというWeb APIを一発呼ぶだけでマルチチャネルのワンタイムパスワードを簡単にできちゃうAPIサービス](https://otp.dev/)を運営している[ラロカラボ](http://lalokalabs.co/)のイクバルです。

[このシリーズの第一回目](https://qiita.com/iqbalabd/items/7b9bf45aa565f29d122b)では、独自のOTPフローを実装するために必要な最初の下準備、およびOTPが送信される共通チャネル間の違いについて説明しました。

あっ、そもそも、「ワンタイムパスパスワード(OTP)」って何？という方いましたら、まず[「今さら聞けない、OTPって何？」](https://qiita.com/iqbalabd/items/791a0188fe06b973890c)を読んでほしい。

この第2回目の記事は、[GetOTPのブログ記事](https://otp.dev/en/blog/208/all-you-need-to-know-to-implement-otp-for-your-site-part-2/)を元記事としてに書いていきます。

https://otp.dev/en/blog/208/all-you-need-to-know-to-implement-otp-for-your-site-part-2/

今回は、以下のことについて説明します。

- 通信チャネルを介したOTPの送信
- お客様からOTPを受け取り、認証する

# 通信チャネルを介したOTPの送信

確認のためにOTPを顧客に送信できるチャネルまたは方法は複数あります。どちらを使用するかは、ビジネスのニーズと、顧客が利用できるものによって異なります。最も一般的なものは、電子メール、SMS、および音声通話です。それぞれのメリットとディメリットは前回の投稿で説明しました。

## 実際にOTPをどのように送信しますか？

OTPを送信する最も一般的でおそらく最も簡単な方法は、サードパーティの通信APIを使用することです。 [Xoxzo](https://www.xoxzo.com/)、Twilio、Vonage、Plivo、MessageBirdなどのサービスは、SMSの送信や電話の発信を可能にするAPI持っているので、それを使えば簡単。

ただ、どの通信APIを使うのか、考慮すべき点がいくつかあります。

- 価格
- サポートされている国とネットワーク
- 国とネットワークの制限
- APIの品質

### 国とネットワークの制限

国によって規制が異なるため、特定の国では、通信プロバイダーに相談し、事前に資料を提供し、メッセージを送信したり電話をかけたりする前に許可が必要の場合があります。単一の国からの顧客のみに送信を行う場合、これは問題ではないかもしれませんが、ビジネスが数か国を超えている場合は、規制を理解し、どこに送信/電話できるかを理解することが重要です。一部の国では、厳しい規制があり、規則に違反した場合は多額の罰金が科せられることも。

そうは言っても、OTPメッセージまたは呼び出しは一般的に契約の遂行に必要なことと見なされます。つまり、それらは本質的に契約であり、ほとんどの場合許可されます。それでも、通信API提供するプラットフォームに確認する必要があります。

### APIの品質

特定のOTPを送信した後、目的の受信者が受信しなかった場合があります。これには原因いろいろありますが、SMSチャネルでよく見られる現象です。
通信プロバイダーは、比較的安価で品質の低い、いわゆる「グレー」のルートを使用することがあります。その結果、メッセージや通話が失われたり、受信されなかったりします。

残念ながら、どの通信プロバイダーが信頼できるかを見つけるために試行錯誤する必要がある部分です。迷っていたらまず[Xoxzo](https://www.xoxzo.com/ja/)でも試してみてください。

## OTPの再送信

特定のOTPを送信した後、目的の受信者が受信しなかった場合や、OTPが受信者に到達したときにすでに有効期限が切れている場合があります。このようなケースに対応するためには、OTPフローに再送信ロジックを組み込む必要があります。ここで言っておきますが、2FA認証システムを実装する際のより複雑な部分の1つになります。

**最も重要なことは、OTPの再送を何回許可するかです。 OTPの再送信の必要性は、思っているより重要で、OTPの再送信を許可しないと、カスタマーエクスペリエンスに悪影響を及ぼします。**

そうは言っても、再送を許可しすぎると、システムが悪用される可能性があります。 OTPの送信は無料ではありません。送信ごとに課金される、SMSや音声などのより高価なチャネルを介して送信する場合は、これを制御できることを確認する必要があります。

# OTPを受信して認証する

プロセス全体の最後の部分は、顧客からOTPを受け取り、それが送信したものと同じOTPであることを確認することです。

Webアプリケーションでは、通常、顧客からの入力を受け入れるフォームを含むビューがあります。このビューは、入力されたOTPが存在するかどうか、および有効期限が切れていないかどうかを確認します。この情報から、どの顧客の電子メールアドレス、または電話番号がOTPに紐付いているかを引き続き識別し、そのアカウントを確認済みとしてマークすることができます。

## 注目すべき点
もしボットアカウントやサービスを悪用しようとする人々などの不正な登録を防ぐことがOTPを採用する理由がメインであれば、もうちょっと注意しないといけないことがあります。

### ある番号でSMS受信できたとしても、受信者が電話を所有しているわけではありません

特定の番号でメッセージを受信できるからといって、受信者が携帯電話を所有し、物理的にアクセスできるわけではありません。匿名の人々が世界中のさまざまな電話番号からメッセージを受信できるようにするオンラインの無料サービスはたくさんあります。これらの携帯番号、ほぼ常に一時的なものです。

### IPアドレスなどの他のデータを組み合わせることでより安全なシステムができる

不正な登録の可能性を特定することは、1つまたは2つのデータポイントだけから行うことはできません。複数のデータポイントを組み合わせて、顧客が誰であるかを明確に把握する必要があります。

すべての場合において、電話番号または電子メールアドレスを常にチェックすることが重要です。サービスの特に機密性の高いセクションに音声などの同期チャネルを使用することも効果的です。これにより、お客様は常に特定の番号番号で連絡できるようになります。

# まとめ
2FA用に独自のOTPフローを実装する際に注意する必要がある手順と事項について、一般的に説明しました。

考慮する必要のある可動部分はたくさんあり、それを正しく、機能させ、安全にするには、多くの反復が必要です。ここLaLoka Labsでは、通信プラットフォームAPIの主な用途の1つがOTPの送信であることがお客様からわかりましたが、OTPの実装自体は反復的で複雑です。彼らは、自分のアプリのビジネスロジックではなく、OTP機能の構築と保守に多くの時間を費やしています。

Webサービスに2FAとOTPが必要な場合は、[GetOTP](https://otp.dev/)にサインアップすることを強くお勧めします。GetOTPは、OTPロジックを簡素化して頭痛や複雑な実装を排除する単純なWebAPIサービスです。 1つのAPI呼び出しを行うだけで、OTPフローのすべてのロジックがGetOTPによって処理されます。

# LaLoka Labs（ラロカラボ）とは
https://lalokalabs.co
LaLoka Labsは、人々が時間とお金を節約し、人間をより幸せにするのに役立つソフトウェアを作ります。