複雑化するパスワード、多要素認証のリスクとは
アプリやWebサービスにログインする際に、求められるIDとパスワード。一般的なパスワードは推測されやすくすぐに突破されてしまうため、特殊文字を含める、最小文字数が決められている、大文字小文字を織り交ぜるなど、パスワードの要件は複雑化の一途をたどっている。池原氏自身も、複雑化するパスワードの洗礼を受けたという。「最も大変だったのが、社内システムでパスワードの最小文字数が64文字だったこと」と池原氏は振り返る。また使うアプリやWebサービスも増えてくる。数が増えると覚えられなくなってくるため、どうしても使い回したくなるが、今はそれも難しい。そこで頼るのがパスワードを記録してくれるパスワードマネージャーだ。
セキュリティを高めるために、従来のIDとパスワード認証を終えた後に、多要素認証を使う方法も増えている。だが池原氏は「これまでの多要素認証（MFA）にもセキュリティリスクがある」と指摘する。たとえばSMSやEメールを使った二段階認証を採用した場合、携帯電波のカバーエリア外でEメールやSMSが届かないというリスクもある。また、サービス提供側にとっては、サービスがスケールするとEメールやSMSを送るコストが重くのしかかるというリスクもある。前職はクラウドコミュニケーションプラットフォームベンダーで働いていた池原氏は、「お客さまから高いとよく言われていた」と明かす。
さらにユーザーにとってMFAは面倒くさい、煩わしいという体験を与えてしまう。しかもMFAを導入したとしても、「フィッシングサイトで本物のIDとパスワードを入力したことで、一気に突破されてしまうリスクもある」と池原氏。デバイスやアプリのセキュリティなども気にしなければならないなど、「このような懸念がありながらも、私たちは現在もIDとパスワードの世界に生きている」と池原氏は言う。
パスワード以外を使用したユーザー認証
ではパスワード以外を使用したユーザー認証にどんなものがあるのか。たとえば従来からあるのはメールでマジックリンクやワンタイムパスワードを送信するなど、パスワードを覚えておく必要がない、覚えさせない方法だ。
またセキュリティキーや、指紋、顔などの生体認証を活用する方法も登場している。「その中でも最近、多くのサイトで導入されている2つの要素技術について紹介したい」（池原氏）
一つがさまざまなWebサイトで導入が進んでいるWeb Authentication（WebAuthn）APIを使用した認証だ。WebAuthnは公開鍵暗号方式を使用するブラウザベースのAPIで、登録したスマートフォンやPCなどのデバイスを要素（認証器）として使用することで、次にログインする際にその要素を使って認証を行うことができる、世界的な認証標準である。機密情報をオンラインで保護するためのより良い代替手段として、主要なブラウザでサポートされている。「この仕組みは非常によく、私自身も今日も使っているが、これまでの利用には課題もあった。それはデバイスごとに登録しなければならない点だ」と池原氏は話す。たとえば1人1台のデバイスの時代なら良いが、今は1人複数台のデバイスを所持している。つまり複数台分、登録するという手間がかかるのだ。
このような手間を解消する手段として、最近、注目を集めているのがPasskeys（パスキー）である。パスキーはWebAuthn APIを利用しつつ、複数のデバイスで共有できる認証の仕組みなのだ。「これが一番の特徴です」と池原氏は語る。
もう一つパスキーの特徴が、ユーザーIDとWebサイトやアプリケーションの両方に紐付けられることだ。認証時にはRelying Party IDを使用することで、自動的にユーザーIDを検出する。「パスキーを使えば、フィッシングサイトへの入力を防止することができる」と池原氏は語る。
パスキーと一口に言っても2種類ある。一つは特定のデバイスに紐付けられたパスキー。これは他とは共有できないことから、「Device-bound passkeys（デバイスにバインドされたパスキー）」と呼ばれている。もう一つがデバイス間やクラウドアカウント間で同期できる「Synced passkeys（同期されたパスキー）」である。その名の通り、一つのIDで登録したパスキーを、同じIDを共有している別の端末でも使うことができる。
パスキーがもたらすユーザー体験と考慮すべきポイント
このようなメリットを持つパスキーをアプリやWebアプリに組み込むにはどうすればよいか。それを可能にするため、2024年1月31日、Oktaは「Okta Customer Identity Cloud （powered by Auth0）」で、パスキーの正式リリースを開始した。「早期アクセスではなく、本番環境で使えるものとして一般提供を開始している」と池原氏は力強く語る。料金プランは複数あるが、無料版を含むすべてのプランでパスキーが使えるという。「既にこのソリューションを使っている方は、有効にしていただくだけ。まだ使っていない人はぜひ試してほしい」（池原氏）
パスキーを使う考慮点についても池原氏は言及した。先行して導入している企業の中では、ユーザーを置き去りにしない設計や、問題が発生したときにどうするかという点について、試行錯誤していることが多いという。
パスキーを使う際に考慮すべき点の第一はユーザー体験をどう設計するかだ。ポイントは3つある。1つ目のポイントはオンボーディング。新規ユーザーはもちろんだが、既存ユーザーへの配慮を十分、考えること。新規、既存ともに強制しないような設計をしながらも、パスキーを使ってもらえるようにいかに促すかを考える。たとえば新規ユーザーであれば、新規登録時に「パスキーを使ってみませんか」とシンプルに提案する。一方、既存ユーザーに対しては、サインインのフローの中に差し込むなどだ。パスワード認証後、パスキーの利用オプションを提示するのである。「Okta Customer Identity Cloudでは、ログインフローの中に提案を挟み込める機能を設けている」と池原氏は加える。
2つ目のポイントはログイン時の体験だ。具体的にはどのようなログイン画面にするのが得策なのか。一つはオートフィルを活用すること。パスワードマネージャーの利用を前提とすることで、IDの入力時に、パスキーが利用できるユーザーにはパスキーの利用を促すダイアログを提示するという方法だ。次にパスキーを使用するためのボタンを明示的に表示すること。こうすることで容易にパスキーでのサインインへと促すことができる。今回紹介したログイン画面では、Googleアカウントでサインインするという選択肢も加えている。ユーザーの選択肢を設けることは、ユーザー体験の向上につながるからだ。
とはいえ、サインインするIDを増やすのは「問題がある」と池原氏は指摘する。いろいろなIDでのサインインを提示しすぎると、ユーザーが混乱するからだ。「そのため既存のサービスがどの認証方式に対応しているのかをきちんとチェックしながら、検討していくことが必要になる」（池原氏）
3つ目のポイントはアカウントリカバリー。たとえばDevice-bound passkeysの場合は、パスキーが登録されている端末を紛失したり、故障したりすることが起きるかもしれない。またSynced passkeysの場合は、パスキーが共有されているアカウントへのアクセスが永遠にできなくなった場合も考えられる。
このような場合を考慮して、「何かしらのフォールバックを作っておく必要がある」と池原氏は言う。フォールバックのよくある手が、登録してもらったEメールアドレスを使って認証してもらうというもの。IDとパスワード認証を行い、リカバリーの際に、再度パスキーの登録をしてもらうというような方法である。Oktaでもパスキー機能を提供する際に、アカウントリカバリーについては社内でかなり議論したという。まだ正解がわからないからだ。「それぞれのサービスにあったパターンで、何かしらのフォールバックを作っておくことが必要だ」と池原氏は言及する。
パスキーを使う際に考慮すべき点の第二は日々進化するOSやブラウザのサポート状況への対応である。OSやブラウザのサポート状況は日々、変化し続けている。たとえば2023年の夏にはmacOSでFirefoxを使うとパスキーを利用できなかったが、イベント直前の2024年1月のリリースで利用が可能になっている。「ブラウザサポートもどんどん進化している。どこに制限があるかは理解する必要がある」と池原氏は言う。
Okataでは顧客と話をすることで、求められている機能を実装していくという。
これまでパスキーに関心を持ちながらも、実装への一歩がなかなか踏み出せなかった人も多かった。だが今後、パスキーは広がっていくことが想定される認証方式である。「ぜひ、我々のプロダクトで試してほしい」最後にこう語り、セッションを締めた。
