ritouです。
いよいよドコモさんもパスキー対応が始まりましたね！いや、これを書いている時点ではまだです。
それよりも、今回はマネーフォワード IDのパスキー対応に注目します。
(4/5追記) マネーフォワード側からも解説記事が出ていました。この記事で言いたいことが全部書いてあります。
ブラウザのパスワードマネージャー機能を利用したパスワード認証のUX
パスキー対応に触れる前に、マネーフォワードIDのパスワード認証のUXから見ていきましょう。
マネーフォワードの「メールアドレスでログイン」のフローを何も考えずに使うと、最初にメールアドレスを入れてからパスワード入力を求めるUXになっています。
このようなUXでブラウザのパスワードマネージャーの機能を使う場合、まず思いつくのはパスワード入力欄が自動的に埋められるパターンですね。
例えばGoogleなども同じようなUXを採用していますが、パスワードマネージャーで複数のクレデンシャルが保存されている場合、メールアドレスの入力欄とパスワードの入力欄でそれぞれ選択するという謎UXに出会うことがあります。(ローカル認証が求められるかどうかなど、ChromeとSafariで挙動が違うところもあるかもですが)
マネーフォワードの場合は、メールアドレス入力欄でパスワードマネージャーのクレデンシャル選択を行うと、スーっとログインできます。
これはメールアドレス入力フォームのところにもパスワードのinputタグを持つことで実現できます。
あー、マネフォのこのメアド入力画面、パスワード入力フォームもおるんやな。だからパスワードマネージャーの選択したらサクサク行けるんか。 pic.twitter.com/8aaWzBS8jp
— 👹秋田の猫🐱 (@ritou) 2023年3月16日
この辺りのブラウザ機能の使い方は参考になるものだと思います。
パスキーでパスワードマネージャー機能を使うための仕組みである "Autofill"
次にパスキーでログインする部分のUXに触れます。
■「パスキー」ログインのご利用方法 下記URLからログインのうえ「パスキー」をご登録いただき、その後「メールアドレスで認証」を選択してください。 URL：https://id.moneyforward.com/webauthn/credentials
上記のパスワード認証でログインした後に、パスキーを設定してみましょう。
設定のところは現状のよくあるUXなので詳細は省略します。
先ほどのメールアドレス入力画面を見てみると、パスキーを設定したことで変化が見られると思います。 Chrome @ MacOS だとこんな感じです。
ここでパスキーのクレデンシャルを選択することで、ローカル認証が要求されてログインできます。 Chromeは同等の扱い、Safariはパスキー優先に見えますがパスワードでログインすることもできます。
このように、ブラウザのパスワードマネージャーの機能をうまく利用しているのがマネーフォワード IDのパスキーでログインするUXの特徴です。このようなUXを実現するために使われているのがAutofill / Conditional UIと呼ばれる仕組みです。
「使える人にだけ使わせる」を実現する難しさ
これまで、パスキーでログインさせるUXというと、次の2つがあったと思います。
- "Identifier-First" メアドなどの識別子を入力し、サービス側でパスキーが設定されていたら要求
- "Identifier-Less(と自分が勝手に名付けて呼んでる)" 「パスキーでログイン」みたいなボタンを押すとサービス側は誰かわからないまま認証を要求
Yahoo! JAPAN は "Identifier-First" 方式を採用しています。また、後者もイメージしやすいのではないでしょうか。
これまで認証関連の登壇をしてAutofillの機能に触れる際は、"Identifier-First" もしくはユーザー識別子とパスワードを同時に入力させるようなUIからパスキーでログインさせるためのショートカット的なものを実現するための仕組みとして紹介してきました。 しかし、今回のマネーフォワード IDの実装をみると「使える人にだけ使わせる」を実現するための現状唯一の方法としてAutofillを採用するものありだと思っています。
"Identifier-First" な方式の場合、次のようなケースでパスキーが見つからないエラーが起こり得ます。
- パスキーを設定した端末だがその後、端末側でパスキーを破棄した
- パスキーを設定した端末とは別の端末を利用している
この辺りの技術に注目している開発者ならばエラーが出てもやり直すフローが整備されていたらなんとでもなるわけですし、エンプラ向けであればマニュアルでカバーも効くでしょう。しかし、一般のユーザーであればそうはいかないですね。
セキュリティキーの利用を許可するか等にも関わってきますが、"Identifier-Less" な方式の場合、ブラウザはなんとかしてパスキーが使えないかという感じのプロンプトを出してきます。このプロンプトも一般のユーザーにとってはなかなか理解しづらいものでしょう。 また、ユーザーが興味本位でボタンを押してしまうことも考えられます。
Autofillを使うと、ブラウザ機能のパスワードマネージャーが判断して選択肢を出してくれます。 これにより、「使える人にだけ表示する」ことが可能になり、これはつまり「使える人にだけ使わせる」UXを実現できるということでしょう。
まとめ
- マネーフォワード IDのログインUXはブラウザのパスワードマネージャーの機能を活用している
- パスキー対応においてもAutofillという仕組みを使ってパスワードと同様のUXを実現できる
- 現状のパスキーでログインするUXにおいて重要なのは「使える人にだけ使わせる」ことであり、ブラウザ/端末側の判断を利用することでそれを実現しようとしているように見える
今日からサポートが開始されると言われているドコモ様には期待しておりませんが、今後パスキーの採用が広まるにあたり使いやすいUXを求めた議論が深められることを期待しています。
追記 : この話についてもうちょっと詳しく2つの記事にしたものを社内ドキュメントとして残しておいたので興味のある方は入社して読んでみてください。
ではまた。
追記: はてブ コメントどうもです
メールアドレスの入力欄とパスワードの入力欄のステップが分かれている UI はSSOでIdPに飛ばすか飛ばさないかをメールアドレスでまず決めてるから、だと思ってたけどそういうことではなく?
いくつかの認証方式をサービス側で判断して要求するケースで使われていますね。(B向けだとSSOのためのドメイン判定、C向けだとY!Jのようにサービス側で認証方式を判断するケース)
パスワード入力欄最初から出しとけや
上記と同じように、識別子で判定できるようにしている中でパスワードマネージャーの利便性を活用している、という認識です。
アレ何なんだろ。「メールアドレスの入力欄とパスワードの入力欄でそれぞれ選択するという謎UX」 / パスワードのinput不可視にするのも行儀悪い。「メールアドレス入力フォームのところにもパスワードのinputタグを持つ」
ユーザー識別子とパスワード入力欄を単純に分けたような作りで、そうなっているところを見かけます > 「メールアドレスの入力欄とパスワードの入力欄でそれぞれ選択するという謎UX」
これは上述のような識別子を先に入れさせるパターンでの利便性向上を狙ったものと想像しています。 前にhidden inputで自動入力の住所などを持っていくパターンがdisられてたことを目にした記憶があるので、今後議論されていくと良さそうですね。 > パスワードのinput不可視にするのも行儀悪い。
あと、autofillに非対応環境があることについて触れるのを忘れていました。 WebAuthn対応環境=autofillが使えるわけではないので、今回のような判断をする際は考慮する必要があります。
