ritou です。
これで話しました。
pwanight.connpass.com
発表資料と発表内容を公開します。
発表資料
speakerdeck.com
発表内容
台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。
今日は、パスキーについて話します。
細かい自己紹介は省略します。
色々宣伝したいものがありますがブログに書きます。
今日の内容ですが、初めにパスキーの概要についてざっと触れます。
続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。
概要からいきましょう。
パスキーの紹介記事もたくさん出ているので要点だけまとめます。
パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策定されています。
最近どこかで見かけた資料にRFCとありましたが、いわゆるWebAuthnはW3Cです。
特徴として、公開鍵暗号による安全性があります。これはネットワークにパスワードのような共有の秘密情報を流さないこと、サービス側は公開鍵のみを保持して漏洩時のリスクを抑えられることがあります。
クレデンシャルの所有者の確認には普段から利用している生体認証などのローカル認証を利用し、パスワードマネージャーによるクレデンシャルの同期機能により、機種変更時や紛失時のリカバリーコストを抑えられるという特徴があります。
サービスからの認証要求に対してブラウザが適切に介入することでフィッシングを検知可能です。
「クレデンシャルを保持している」という所有要素とローカル認証の2要素認証を単体で実現可能なので、パスワード認証の代わりに使えますねというところです。
パスキーの現状として、去年からプラットフォーム、ブラウザの対応が進められました。
具体的にはWebAuthn APIへの対応、パスワードマネージャーへのパスキー保存の部分です。
ある程度動作する環境が整ってきたので、パスキー認証を採用するサービスが増えてきたところが"今"です。
対応サービスが増えると、ユーザーにも馴染みが出てきて、パスキーが使われる状態になるでしょうという流れなのですが、まだまだパスキー対応のプラクティスが十分ではないため、サービスの開発者がまずは先行しているサービスのパスキー認証を利用し、特徴を理解する必要があるでしょう、というのが現状かと思います。
そこでこの本ですね。「まずは使ってみよう。」と。
ここまで話したパスキーの概要についての解説もしているので、是非読んでみてください。
さっきの本を読むと、パスキー対応の意欲が湧いてきます。
ここからはWebアプリというか自サービスに導入するための話をしましょう。
パスワードレスへの道を意識してみましょう。
パスワード認証だけを実装していたサービスは、何らかの攻撃を受けたり、危機意識から2要素認証、2段階認証などを実装しました。
そして、今起きているのは、これまでの認証方式に加えてパスキー認証に対応するというものです。
これができたあと、新規登録時のパスキー登録やパスワード認証の無効化ができると、ようやくパスワードレスが完成します。
しかし、世の中の反応は残酷です。
某Amazonのように、やっとパスキー対応したぞ、となっても「パスワードを無効化できないなら意味ない」みたいな反応がされることもあります。
これはユーザーの期待が現状を超えてしまっている状態だと言えるでしょう。そういえば9月あたりの不正ログインの件はどうなったんでしょうか？
話を戻して、いわゆるパスキー認証への対応としての最低限の実装を紹介します。
それは「パスキーの管理機能」と「パスキー認証を用いたログイン」です。
パスキーの管理機能については、先行して実装したサービスを参考に実装すればある程度迷わずにできるでしょう。
悩みどころとしては、やはりログインのUI/UXのところでしょう。
既存の認証方式に対してどのようにパスキー認証を絡めていくかを考える必要があり、先行して実装したサービスを見ても実装パターンがいくつかあります。
ここからは、ログインUI/UXの実装パターンを紹介します。
まずは Identifier-Firstと呼ばれる実装パターンです。
GoogleやAmazonのように、最初にユーザー識別子を入力するパターンです。
これら2つでも細かい違いがあります。
Googleの場合、パスキーの登録状況や環境から、パスキー認証を要求するかどうかを判断します。
Amazonは同様の判断の結果、パスキーでログインするボタンを表示します。あくまでユーザーが選択するもの、という意図なのでしょう。
このIdentifier Firstパターンは、2FAとしてセキュリティキーが利用されていた頃、つまりFIDO認証が始まった当初からあったものと言えます。
「パスワード認証の後にFIDO認証が要求されるフロー」から、パスワード認証が取り除かれてローカル認証が必須になった、と捉えられます。
サービスがパスキー認証を要求するかどうかを判断するわけですが、当然ながら登録されているパスキーがあってもこの環境でそれが利用可能かわかりません。
このため、過去の利用実績を何らかの方法で覚えておいたり、パスキーの登録時の情報と現在の環境を照らし合わせる、などをして判断しているところもあると聞きます。
そして、Amazonのようにユーザーに選択させるところはその分ステップが多くなりますね。
続いて、username lessパターンというものです。
GitHubでは、「Sign in with passkey」というボタンがあり、そこからパスキー認証が始まります。
これは、ユーザー名やメールアドレスといったユーザー情報と一緒にクレデンシャルが保存できるようになった、ResidentKeyやClient Discoverable Credentialといったものが出てきた頃UI/UXです。
セキュリティキーしか使えなかったところから、PCやスマホのTPMにクレデンシャルを保存できるようになったあたりですね。
ボタンを押すとこの端末で利用可能なパスキーで認証する、という流れですが、こちらもボタンを押すまで利用可能なパスキーがあるかはわかりません。また、パスキーが登録されていないユーザーも間違って押してしまうかもしれません。この辺りが課題としてあります。
最後に紹介するのが、Passkey AutofillやConditional UIと呼ばれるものを利用するパターンです。
ここで、少し視点を変えてパスキーを考えてみましょう。
パスキー認証は「パスワードマネージャーを利用したパスワード認証」をより進化させた認証方式なのです。
パスワードマネージャーの利用を強制させた上で、「公開鍵暗号方式」と生体認証などの「ローカル認証」を組み合わせたFIDO認証を実現できます。
パスワードマネージャーを利用したパスワード認証では、次の部分がパスワードマネージャーやプラットフォームに依存します。
同一サービスとして扱うかどうかのドメイン判定、パスワード保存時のユーザー名やメールアドレスの扱い、候補として出てきたパスワードを選択した後のユーザーアクションなどです。
また、フィッシング耐性という面では手動のコピペが可能であることが抜け穴となりますし、そもそもサービスはユーザーにパスワードマネージャーの利用を強制できません。
Passkey Autofillではパスワードの時と同様のUXを実現できます。
その上で、対象のドメインやオリジンの値、ユーザー情報をサービスが指定できますし、パスワードのコピペ的なものはありません。
選択後にローカル認証を必要とするかについても、サービスが指定できます。
このPasskey Autofillに対応するサービスも増えてきています。
私が関わっているMIXI Mというサービスは、パスワード認証を利用せずSMS/Email OTPによる認証を採用してきましたが、Passkey Autofillに対応しています。
ユーザー識別子を先に入力するIdentifier FirstパターンのようなUI/UXにもPasskey Autofillを適用可能です。
Passkey Autofillを活用しているサービスとして、マネーフォワード IDがあります。
Identifier Firstパターンを採用しているサービスでは2回Autofillの選択を行う必要があるところも多いですが、
マネーフォワード IDではメールアドレス入力フォームがあり、そこでAutofillの選択を行うとパスワードの場合でもスルッとログインできます。
「パスキーでログイン」というボタンを押させるという新しい体験をさせずに、これまでと同様の体験のままパスキーを利用可能にしているところは現状最も参考になるUI/UXだと言えるでしょう。
まとめです
Auth屋さんの本を買ってパスキー認証の特徴を正しく押さえましょう。
Webアプリケーションへの導入において、最低限の機能は「パスキー管理」と「ログイン」であることを意識しましょう。
ログインのUI/UXは3種類ぐらいに分類できて「Passkey Autofill」がオススメです。
質問など、いつでもお待ちしています。
ありがとうございました。
質問があったら？
Xでこの記事へのリンクをつけつつ聞いてもらえたらと思います。
ではまた。
