ritou です。
前回、こんな記事を書きました。まず読んでみてください。
パスキー対応をするにあたり、パスキーを使いたい人が普通に使える のは当たり前ですし、どのサービスもそこはそれなりに実装するものです。 ただ、実際にユーザーに使ってもらうとなった時、パスキーが使えない状況だとかパスキーを使いたくないユーザーが不満を覚えてしまうことが先行サービスへの反応からわかってきています。そこで、一歩踏み込んた観点を整理したというのが前回の記事の内容です。
今回からは、この観点でいろんなサービスのパスキー対応を見ていきたいと思います。 どこから見ていくのかというところですが、最近対応がアナウンスされていた日経IDのパスキー対応を見てみます。
日経IDのパスキー対応内容
日経IDのパスキー対応ってどんな感じなの？というところで、昨年末のアドカレで紹介されていた内容から変わってなさそうです。
開発者目線でパスキーのことを考えたことがある場合は上記記事から対応内容が見て取れると思います。
嫌われる実装になっていないかの考察
3つの機能単位で見ていきます。
- 登録促進
- 管理
- 認証
1. 登録促進
アカウント設定のトップ->セキュリティと辿ると、パスキー未登録の場合は説明が上の方にあります。
ログイン直後に登録を促すパスキープロモーションなどは行なっていないようです。これであれば「パスキー登録しろってうるさい」みたいな反応は出ないでしょう。
その分、実際に登録してくれるユーザーの数はなかなか増えない(意識高い系のみ登録してくれる)という状況は考えられますが、そこは今後は頻度などを考えて実装してもらえたら良さそうですね。
2. 管理
管理については基本を押さえた実装になっているように見受けられます。
セッション管理との絡みとかいくらでも細けぇ改善などもできる余地はありますが、プラクティスとして出てきたら対応してもらえば良いでしょう。
3. 認証
ここが本番です。
- パスキー未登録ユーザー×パスキー認証
- パスキー未登録ユーザー×パスキー以外の認証
- パスキー登録済みユーザー×パスキー認証
- パスキー登録済みユーザー×パスキー以外の認証
それぞれ見ていきましょう。
1. パスキー未登録ユーザー×パスキー認証
これは パスキー未登録ユーザーがパスキー認証のフローに迷い込む余地 の話です。
"パスキーでログイン" リンクが見えます。Autofill非対応環境への配慮ですね。 ユーザーの責任とも言ってしまえばそれまでですが、これを誤って押してしまいなんなんだ？となるケースは一定ある ことを意識しておきましょう。 ダイアログにモバイル端末とかセキュリティキーとか出てきちゃうのに我々は慣れていますが、そうではないユーザーの方が大多数だということです。 開発者としてはなるべくパスキー認証させたいんや！というところですが、個人的には Autofill非対応環境はパスキー非対応環境 ぐらいで割り切ってもいいかなと思います。
2. パスキー未登録ユーザー×パスキー以外の認証
パスワード未登録ユーザーがメールアドレスを入力すると、ユーザーの識別とパスキーの登録状態がチェックされた結果、パスワード入力フォームが表示されます。パスワードマネージャーにパスワードが保存されていてそれを選択する場合も、パスワード入力フォームに自動入力されます。これは特に問題なさそうです。
3. パスキー登録済みユーザー×パスキー認証
Autofill対応環境であればしれっとログインできます。
Autofill非対応環境でも、リンクからパスキー認証のダイアログに続けられます。 手元の端末にパスキーがない場合でも、Hybrid Transportによりゴリ押しは可能です。
Autofillでメールアドレスを入力して続けた場合も、ユーザーの識別とパスキーの登録状態がチェックされた結果パスキー認証を促されます。
このボタンからはallowCredentialsに値が指定されます。パスキー使わせたいという気持ちが伝わってきます。
このような実装が問題になり得るのは 手元にパスキーがなく、Hybrid Transportも使えない ようなケースですね。 嫌われるランキング第一位のエラーである "パスキーがありません" が発動する可能性があります。 これは、Identifier-Firstと呼ばれる実装パターンの特徴と上記のワンボタンログインの特徴の合わせ技、というか落とし穴というかそんなところです。
もちろんパスワード認証へのリンクもあるのでどん詰まりにはなりませんが、一般ユーザーにとっては "エラーを見せたら負け" なところもあるので反応などを見て改善などを考えてみてもよいのではないでしょうか。 この辺りで参考になりそうなのはやはりマネーフォワード IDのログインフローでしょう。
- Autofill付きのメアド入力フォーム
- Autofill付きのパスワード入力フォーム(allowCredentialsあり)
と多段でAutofillを仕掛けつつ、パスワード認証へのフォールバックも自然にできるようにするのが現状のベストプラクティスでしょう。
4. パスキー登録済みユーザー×パスキー以外の認証
ここではさらに2パターンを確認します。
- パスキー対応環境だがパスワード認証を使いたい
- パスキー非対応環境
パスキー対応環境でユーザーがパスワード認証を選択するケースから見てみます。 手元にパスキーがない状態はどうしても考えられるわけで、その時にメールアドレス入力フォームのAutofillではパスワードを選択できる場合があります。 パスキー登録済みユーザーが最初のAutofillでパスワードの項目を選択しても、日経IDではパスキー認証を求められます。
これは結局ユーザー識別とパスキーの登録状態を確認してその後の処理を判断するためですが、気になるのは "ユーザーはパスワード認証を選んだ" にも関わらず、"パスキー認証が要求される" ということです。そこからパスワード認証に進むにはワンクリックが必要なのです。 パスキー認証を優先したいという思想から来ているのだと思いますが、これがどういう反応をもたらすのかは少し気になりますね。
改善策としてはこちらもマネーフォワード IDがやっているhiddenなパスワードフォームといったものがあります(どんだけベストプラクティスの塊なんだ)。参考にしても良いかもしれませんね。
最後に、非対応環境も見てみましょう。
日経IDはパスキー非対応環境でもユーザー識別とパスキーの登録有無を判断してパスキー認証を要求するように見えます。そしてボタンを押しても何も起こらない。繰り返しになりますが、パスワード認証へのリンクはあってもユーザーに混乱を与えてしまうことは避けたいですね。 改善案としてはメールアドレス入力フォームの表示の時点などで環境をチェックし、それも踏まえてどの認証を要求するかを決める方が良いかもしれません。Yahoo! JAPANなどはそうしてますね。
まとめ
嫌われないための観点から日経IDの挙動を確認しました。 色々細けぇ話を書きましたが、パスキーを使いたいユーザーにとっては問題なく使えるでしょう。 パスワードを使いたいケース、パスキーが使えないケースで一手間かかってしまう点にどのような反応が出てくるかに注目してもらえたら良さそうです。
別のサービスについても見ていきたいと思います。自分のところも。
告知
3月末はパスキー祭りと言っても良いでしょう。
まずは前回に引き続き iddance です。
次の日の昼には私がお話しします。
記事を書いてる時点では265人ですって。Findyさんの集客力すごいですね。
ではまた。
