こんにちは。サービス開発課の田畑です。
最近は、パスワードに代わる認証方式として「パスキー」が注目されています。
業務の中でパスキーについて認証画面の構成も含めて調査・検討する機会がありました。
調査を始める前は「パスワード入力の代わりに生体認証を使う仕組み」というイメージでしたが、実際に調査を進めていくと、技術そのものよりも利用者が迷わないUIを設計する難しさを感じました。
今回は、パスキーの概要と、画面設計を考える中で気付いたことを紹介します。
パスキーとは
パスキーは、パスワードの代わりにスマートフォンやパソコンの生体認証、PIN、画面ロックなどを利用してログインする仕組みです。
初回の登録さえ済めば、その後は登録端末を使って簡単にログインすることができるようになります。
パスワードを忘れたり、入力ミスを気にしたりする場面を減らせることもメリットの一つです。
パスキーの仕組み
パスキーでは「公開鍵」と「秘密鍵」という対になった鍵を利用します。
登録時には端末側に秘密鍵、サービス側に公開鍵が保存されます。ログイン時には端末内の秘密鍵を利用して署名を行い、サービス側が公開鍵で本人確認を行います。
重要なのは、秘密鍵そのものがサービス側へ送信されることはないという点です。
そのため、パスワードのように認証情報を入力する必要がなく、フィッシングサイトへの入力や情報漏えいのリスクを抑えられる仕組みになっています。
利用者は公開鍵や秘密鍵を意識する必要はありません。
普段利用しているスマートフォンやパソコンの認証機能を使うだけでログインできます。
パスキーの主な特徴は次の通りです。
- パスワードを覚えたり入力したりする必要がない
- 秘密鍵は端末の外へ送信されない
- サーバーには公開鍵のみ保存される
- 顔認証や指紋認証など、普段の端末操作に近い方法で本人確認できる
利用者はこうした仕組みを意識する必要はなく、普段利用している端末の認証機能を使ってログインできます。
選択肢が増えれば便利？
調査を始めた頃は、
- パスワード
- パスキー
- 認証アプリ
- バックアップコード
など、多くの認証手段を用意すれば利用者も便利になるだろうと考えていました。
しかし画面構成を考えると、認証手段が増えるほど画面も複雑になります。
利用者にとっては、
「どれを選べばいいのか」
が分からなくなる可能性があります。
技術的に可能なことと、利用者にとって分かりやすいことは必ずしも同じではないことに気付きました。
パスキー特有の難しさ
通常のフォームであれば、Web画面上で入力からエラー表示までを制御できます。
一方でパスキーは、ブラウザーやOSが認証UIを表示するため、制御できない箇所があります。
そのため、
- 認証をキャンセルした
- 生体認証に失敗した
- 利用できるパスキーが存在しない
といった状況が発生した時に、Web画面側は、その結果を受け取って利用者へ分かりやすく案内する必要があります。
「認証そのもの」よりも、
「認証の前後をどう案内するか」
の方が大きなテーマになるように感じました。
UI設計や導線設計の重要性
認証技術を調べていると、
- WebAuthn
- FIDO2
- 公開鍵認証
など様々な用語が登場します。
しかし利用者にとって重要なのは、
- ログインできるか
- 次に何をすればよいか
- 困ったときにどうすればよいか
です。
例えば、パスキー認証に失敗した場合に単に「認証に失敗しました」と表示されても、利用者は次に何をすればよいか分かりません。
技術的に優れた認証方式であっても、利用者が迷ってしまえば使いにくいサービスになってしまいます。
認証方式の検討を通して、改めてUI設計や導線設計の重要性を感じました。
まとめ
パスキーは安全性や利便性の面で注目されている認証技術ですが、実際に画面設計を考えてみると、単純にログイン方法を置き換えるだけではありませんでした。
認証手段の選択、エラー時の案内、OSやブラウザーとの連携など、多くの考慮すべき事項がありました。
新しい技術であっても、使う側にとって使いにくいものであれば不便になってしまいます。
今後も新しい技術などを検討する機会があると思いますが、利用者にとって分かりやすいUI設計や導線設計も重要課題として取り組んでいきたいと思います。
