パスワード再設定のUIおよびフローの重要性は高まりつつあります。
多くのサイトが独自のアカウントシステムをもつようになり、ユーザーは認証情報を管理するのが難しくなっているためです。サイトごとの多様なパスワード設定ポリシーのせいでパスワードの使い回しができず、記憶でカバーすることはもはやできません。どこかのサイトが勝手に情報流出したせいで、自分のパスワードなのに変えろと要求されることもあります。
この記事では私が多くのサイトでパスワード再設定をしていて思うことについて書きます。
基本的なパスワード再設定のフロー
基本的なパスワード再設定のフローは下記の通りでしょう。
- ログイン試行・失敗
- パスワード再設定ページに遷移
- メールアドレス再入力
- メールアドレス宛にトークン付き再設定URLが届く
- 届いたURLへアクセスし、新しいパスワードを設定
- 再度ログイン試行
- （再設定したパスワードで）ログイン成功
一般的なフローですが、ただパスワードを再設定をするだけでこのステップ全てを踏まなければなりません。私が好ましくないと思うのは③のメールアドレス再入力と⑥・⑦の再ログイン試行ステップです。
ユーザーにメールアドレスの再入力をさせるな
ユーザーに入力してもらう箇所をなるべく減らすよう工夫すべきです。最初のログイン試行ステップでユーザーが認証情報として使いたいメールアドレスは推察できるはず。であれば下の動画のようにするのが良いでしょう。
このデモはユーザーの入力を軽減できる良い例です。最初のログイン試行時にメールアドレスを保持し、その値を再設定用URL先アドレスの初期値として補完します。こうすることでユーザーは同じアドレスを2回も入力せずに済みます。
- ログイン試行・失敗
- パスワード再設定ページに遷移
メールアドレス再入力- メールアドレス宛にトークン付き再設定URLが届く
- 届いたURLへアクセスし、新しいパスワードを設定
- 再度ログイン試行
- （再設定したパスワードで）ログイン成功
パスワード再設定のステップが減りました。
再設定後はログイン済み状態にする
メールアドレスに再設定用URLが届いたら、ユーザーは再設定ページにてパスワードを再設定します。再設定が完了したらログイン画面へ遷移せず、ログイン済み状態にすべきです。
パスワード再設定はメールまたはSMSで本人認証を行います。つまりメールを見れる・SMSを受けとれる権限を、パスワード（認証情報）を変更できる権限としていることになります。認証情報変更権はログイン権限より上位にあるので、パスワード再設定後のログインステップは不要です。
再設定後、ログイン済み状態にすることでよりユーザーの労力軽減につながります。これでより便利なサイトになりましたね。
おまけ：技術的にどうやるの？
サイトの作り（SPAと Multi Page App. ）によってログイン時に入力されたメールアドレスを保持する方法が違います。
SPAの場合
- 入力されたアドレスをグローバル変数にバインディングする
- 同一ページ内にログイン機能とパスワード再設定URL送信機能をもたせ、同一変数にアドレス値を格納する
MPA（従来型アプリ）の場合
- ログイン試行時に送信されたアドレスを再設定URL送信ページ遷移時のパラメータとして送信させる
この記事の 最終更新：2023.5.6