OCTOMO — 顧客が自分でSMSを送る（MO）方式の携帯電話本人確認API
(octomo.octoverse.kr)サービスに会員登録の本人確認を組み込むたびにSMS送信コストが負担になるため、発想を逆転させて作った携帯電話認証APIです。
従来のSMS認証は、サービスがユーザーに認証SMSを送信します（MT, Mobile Terminated）。1通あたり9〜50ウォンに月額基本料までかかるため、ユーザーが増えるほどコストが大きくなり、契約・審査のために連携完了まで1〜2週間かかることもあります。
OCTOMOはこの方向を逆にしました（MO, Mobile Originated）。ユーザーが自分の携帯電話から指定された番号へ認証コードをSMSで送り、サービスは受信したメッセージをAPIで照会するだけです。SMSを送る主体がユーザーであるため、サービス側には送信コストが発生せず、ユーザーが実際にその端末からSMSを送ったという点で所持認証になります。
フローとしては、認証ボタンを押すとSMSアプリが宛先番号と認証コードがすでに入力された状態で開き、ユーザーは送信ボタンだけ押せばよい方式を推奨しています。(
sms:ディープリンクで処理するためフロントエンドで実装する部分ではありますが、モバイルではこれが定石です。) 番号の入力ミスやコードの打ち間違いが起きないので、失敗率も一緒に下がります。APIは実質的にエンドポイント1つです。
POST /octomo/v1/public/message/exists
- 入力: 携帯電話番号 + ユーザーが送ったコード
- 出力: 直近5分以内に該当コードのSMSを受信したかどうか (
verified: true/false)連携フローは「ボタンをタップ → SMSアプリ自動起動（番号・コード自動入力） → ユーザーが送信 → このAPIを呼び出してtrueになれば通過」程度なのでシンプルです。別途アプリのインストールやSDKは不要で、REST呼び出しだけで済み、Node/Java/Pythonのサンプルをドキュメントに入れてあります。
正直な制約も書いておきます。
- ディープリンクで入力の手間はなくしましたが、ユーザーが送信ボタンをもう一度押すという操作ステップは残ります（送信コスト0ウォン・所持認証強化とのトレードオフ）。
- 韓国国内の携帯電話番号ベースのため、海外ユーザーは対象外です。
- ユーザーには自身の料金プランのSMS料金が適用されます（無制限プランなら実質無料）。
特に「このフローだとユーザー離脱が大きくならないか」といったUX面の懸念や、セキュリティ観点での指摘を聞きたいです。フィードバック歓迎です.
5件のコメント
本人確認と占有認証では、それぞれ満たすべき法的要件が異なるため、本人確認を使わなければならないケースがあると理解しています。どのような場合にこの占有認証だけでもよいのかについて、もう少し詳しく書かれているとよかったですね。
フィードバックありがとうございます！
ご指摘のとおり、本人認証と占有認証では満たす要件が異なるため、
どのような場合に占有認証だけで十分なのか、その基準をドキュメントでより明確に整理して追記します。
的確にご指摘いただき、ありがとうございます！
おお、一度はあってほしいと思っていたものですが、APIがとても使いやすくできていますね...!
「ユーザーが自分の携帯電話から指定された番号に認証コードをSMSで送信し」
この部分が少し紛らわしいのですが、OCTOMOが提供する番号にSMSを送るよう案内する、ということですよね？
はい、その通りです！ OCTOMOが提供する番号宛てに認証コードをSMSで送信するようご案内いただければ大丈夫です。
アプリ環境では
sms:ディープリンクを活用し、ユーザーが認証ボタンを押した際にメッセージアプリが自動で開くように実装されることをおすすめします！Web環境では現在、認証コードをSMSで送信する方式を提供しており、あわせてQRコード方式も開発中です。
ユーザーがQRコードを読み取ると自動的にメッセージアプリへ切り替わるよう実装しています！
ありがとうございます！
わあ、とてもいいですね……サイドプロジェクトでうまく使わせていただきます（笑）