🙆

続:FIDO認証できるユーザーをスキャンさせない設計を考える - パスキーのログインUX

2023/12/18に公開

Security

ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2023 シリーズ2 の記事です。

なんの話か

自分が関わっているサービスでは、パスキーによる認証をサポートするまでは、SMS/Email OTPによるユーザー認証のみを採用していました。

その頃から、"あるSMS番号やメールアドレスが登録済みかどうかを第3者に知らせない(自分の投稿では"ユーザーをスキャンさせない"と表現しています)" というポリシーを定めていました。昨年の会社のアドカレに書いた記事でそれに触れています。

今回は、パスキー対応するにありいくつかあるログインのUXパターンに "ユーザーのスキャン" という観点を入れた整理をします。

3つのログインUXパターン

最近、パスキーのログインUXにはいくつかのパターンがあって、特徴が異なるよというお話を勉強会でしました。

Identifier-First: ユーザー識別子を先に入力し、パスキーの登録有無で動きが変わるやーつ
Usernameless: 「パスキーでログイン」みたいなボタンから始まるやーつ
- Passkey Autofill: パスワードマネージャーで管理されているパスワードの候補と "同様" に、利用可能なパスキーの候補も表示されるやーつ

他の方の記事で、Identifier-First　+ Passkey Autofill も採用しているところがありますが一旦置いておきます。

それぞれのパターンを採用した際に、ユーザーのスキャンが防げるかどうかを整理しましょう。

Identifier-First

まだ "Client-side discoverable credentials" と呼ばれる、ユーザー情報と一緒にクレデンシャルを認証器に保存する仕組みも十分に普及していなかったころのお話です。最初にユーザー識別子を入力し、パスキーが登録されていたらパスキーによる認証が要求される、Yahoo! JAPANのようなUXを検討しました。

当初からSMS番号やメールアドレスだけを入力し、そこにOTPを送信するスタイルをとっており、そのUXをなるべく踏襲した形でパスキー(当時はパスキーという用語がなかったのでFIDO)に対応できるかなと言うところでした。

当然ながらこれは認証要求の時点でパスキーを登録しているかどうかが第3者にわかってしまう仕組みです。一瞬、"パスキーを登録しているユーザーだけならいいか?妥協しちゃうか?"とも考えつつ、自分たちが設定したポリシーを尊重して没となりました。

一応、Identifier-Firstのパターンでユーザーのスキャンを防ぐ方法についても検討しました。

未設定ユーザーの場合、ダミーの公開鍵を allowCredentials で指定

今となってはもう参考にはならない残念記事 ですが、手元で実装までしました。

Usernameless(パスキーでログインボタン)

続いてはパスキーでログインというボタンです。

これは、ユーザー名やメールアドレスといったユーザー情報と一緒にクレデンシャルが保存できるようになった、ResidentKeyやClient Discoverable Credentialといったものが出てきた頃のUI/UXです。セキュリティキーしか使えなかったところから、PCやスマホのTPMにクレデンシャルを保存できるようになったあたりですね。

ボタンを押すとサービス側が「誰でもいいからパスキーでログインしてこいや」と認証要求してくるパターンなので、ユーザーのスキャンは防げます。ソーシャルログインでは当たり前と言えるぐらい浸透しています。しかし、これを検討していたのがまだGitHubとかもパスキーを採用していない頃だったので、圧倒的に "パスキーでログインというボタンや用語に慣れていない" 状態なわけです。

ボタンを押すとこの端末で利用可能なパスキーで認証する、という流れですが、こちらもボタンを押すまで利用可能なパスキーがあるかはわかりません。また、パスキーが登録されていないユーザーも間違って押してしまうかもしれません。この辺りが課題としてあります。

この辺りの課題を考慮して、この時点でのパスキー(FIDO)対応を少し見送ることにしました。

Passkey Autofill

そんなこんなで悶々と過ごしていると、パスキーという用語が出回り、Passkey Autofillに対応するブラウザとサービスが出てきました。

Usernamelessの時点でスキャン対策はできており、良い意味で新しい体験をなるべくさせないようなパターンである ということで、ある程度非対応環境があるとはいえ、これで行こうと決まりました。

Passkey Autofillでこのような表示をする際にサービスはこの環境で利用可能なパスキーがあるかどうかがわかりません。わかるのは、ブラウザを利用しているユーザーだけです。サービス側で出しわけを行わなくてもブラウザが仲介して「この認証方式が使えるよ」と教えてくれる仕組みは、ソーシャルログインにおいても改善の余地があるところですが、今のところパスキーの方が優れていると言えるでしょう。

まとめ

パスキーのログインUXを検討する際に、ユーザーのスキャンをさせたくないという観点を入れたというお話でした。

Identifier-Firstパターンでは、ユーザーのスキャンが可能。対策をしようと思ったら使い物にならなそうなのができたので没
Usernamelessパターンではユーザーのスキャンを防げるが、押してもらいたい人に押してもらえるか、押してもらいたくない人にも押されそうみたいなのを考えて没
Passkey Autofillでもユーザーのスキャンを防げるし利用可能なパスキーが表示されて選択できるというUsernamelessよりも優位性があるので、自分のところでは採用

今から検討するなら普通にAutofillに全ベットで良いでしょう。

おまけ

ではまた！