アプリ時代、というかバックエンドがAPIな時代に、メールアドレス確認処理をどう実装していくか考えたメモ。
概要
- 一般的なメールアドレス確認処理をユーザーに強いられるアクション、導線、実装内容あたりで良し悪しを一旦整理
背景
- なんだかんだ言って、世の中のいろんなサービスを利用する際にメールアドレスが必要、メールアドレスの確認処理ではいろんな実装がある
- 送るタイミングは色々にせよ、確認メールにURLが含まれていて、それをクリックしたら確認完了＆戻れみたいなのが思い浮かぶが、それだともちろんWebのエンドポイントも必要になる
- 電話番号認証(SMS)ではキャリアの迷惑メール対策とかからURLではなく認証コードを送るのが一般的なきがするが、メールの場合でも同様でいいのではないか? API実装のみで済ませたい
この背景があるので、以下の文章にはどうしてもURLdisなバイアスがかかってしまうだろうなとは認識している。
URL vs 認証コード
比較対象
最小限の単位で切り出して比較する。
- URL
- 1. メールアドレスを入力し、確認メールが送られる
- 2. メールを確認
- 3. URLをクリック
- 認証コード
- 1. メールアドレスを入力し、確認メールが送られる
- 2. メールを確認
- 3. 認証コードを（機械的 or 記憶能力を用いて）コピー
- 4. 認証コードを入力
ユーザーの手間
- URL
- 簡単
- 認証コード
- コピペが必要なので、URLクリックよりは面倒
確認後の導線
- URL
- URLを開いた先が「メールアドレスを確認しました。おつです」程度なら、メールアドレスを入力した環境(アプリなりなんなり)に戻る必要がある
- 認証コード
- メールアドレスを入力した環境に認証コードを入れるため、その後の処理にはスムーズに進められる
例えばアプリからのメアド登録の場合、URLをクリックしてブラウザを立ち上げるまでは簡単で良いが、その後にアプリ側で処理を続けるところで離脱が起きてしまわないかちょっと心配である。
実装内容
- URL
- メールアドレス入力させる機能
- 確認メール送信
- アクセスされたら確認済みにする処理を行うエンドポイント(=Webアプリケーション)
- 認証コード
- メールアドレス入力させる機能
- 確認メール送信
- 認証コードを検証する機能
URLの方は確認済みにする処理のためだけにWebアプリケーションを用意する必要があるってのはちょっと...という思いがある。
乗っ取り対策
メールは本人しか見れない&悪い人がそのメアドの確認したいと思っているという前提。
- URL
- 「メールで送られてきてるURLふんでおいて」
- 認証コード
- 「メールで送られてきてる認証コード教えて」
細かい話をすると、URL踏ませる方が成功の可能性はたかそう
...とはいえ、このレベルになると、あんまり変わらなそう。
一旦まとめ
- 一長一短
- アプリがメインであれば、確認済みにするためのWebのエンドポイント作りたくないっていう理由で認証コード使っても大丈夫そう
もしメールアドレスの確認が任意だったら
認証コードよりもURLでやるのが簡単そう。
その他
- そもそもGETのリクエストで重要な処理させるやり方についても色々言いたいこともなくはない
- メールアドレス確認だけで考えたらこれでいいが、例えばパスワード忘れでメールを送るとかになると再びこの話が出てきそう