株式会社MIXI 開発本部 MIXI M事業部の ritou です。
DroidKaigi 2023にてお話しさせていただきました。
資料も公開しました。
今回も発表内容全部書き出してみたをやってみます。
同時通訳ありだったので台本はできていて、この通り話せたら良いだけだったのですが実際はそううまくいかずに普通に時間なくなりました。
それではどうぞ。
これからパスキーに関するユースケースと、それに伴うユーザーエクスペリエンスの課題について発表します。
株式会社MIXIでエンジニアとして働いています。
MIXI MというサービスでID基盤の開発に携わっており、8月にパスキー対応を行いました。
その経験も踏まえて、今日はお話をさせていただきます。
また、OpenIDファウンデーションジャパンでエバンジェリストをしています。
今日はID連携とパスキーの関係についてもお話します。
この発表を通して、みなさんにはつぎの4点についての理解を深めていただきたいと思います。
- パスキーの概念
- 代表的な2つのユースケース、そして関連する機能
- コンシューマ向けサービスにおけるUXの課題
- ID連携との関係性
それでは、パスキーの概念から始めましょう。
おそらく、多くの開発者がユーザー認証に対して次のような認識を持っているでしょう。
「パスワード認証は脆弱だ。ユーザーは推測が困難な文字列を作成できず、同じパスワードを複数のサービスで使い回し、フィッシング攻撃にも引っかかる。一つのサービスで情報が漏洩すれば、他のサービスでも不正ログインされてしまう。」
一方で、パスキーを用いた認証は、これらの課題を解決する素晴らしい方式だと、誰かが言っている。こんなところではないでしょうか。
今日はその解像度を少し高めてみましょう。
実は脆弱なのはパスワード認証自体ではありません。
パスワード認証を使いこなせていない、人間です。
さきほど挙げたような脆弱な点は、すべて人間がパスワードを考え、記憶し、入力した結果です。
よって、その解決策は、それをシステムが行うことです。
パスワードマネージャーを考えてみてください。
安全なパスワードを生成し、サービスごとにそれを管理できます。
ドメインを判別する機能があるため、フィッシングサイトに引っかかる可能性は低くなります。
使いまわしをしないので、一つのサービスでパスワードが漏洩しても、その影響は限定されます。
このように、多くの課題は解決されています。一つを除いて。
それは、サービスがユーザーに対しパスワードマネージャーの利用を強制できないという点です。
パスキーは、システムによるクレデンシャル管理と入力をユーザーに強制できます。
このポイントは、今日ぜひとも覚えていただきたいです。
パスキーのベースとなる技術であるFIDOには主に2つの特徴があります。まず一つ目は、公開鍵暗号方式による高い安全性です。
秘密鍵を管理する認証器とサービスとの間で交換される情報は、登録時には署名と公開鍵、認証時は署名のみとなります。
サービス側で保存されるのは、公開鍵だけです。これにより、パスワードが漏洩した場合と比べ、リスクが低減されます。
もう一つの特徴は、生体認証や端末固有のPINなど、ローカル認証による高い利便性です。
このローカル認証において、生体情報やPINの値がインターネット上を流れることはありません。普段から利用している画面ロックの解除方法を使用して様々なサービスを利用できます。
FIDO2という規格によりウェブアプリでFIDOが利用可能になりました。
FIDO2は、ブラウザAPIのWebAuthnと、認証器とブラウザ間の通信プロトコルであるCTAPによって構成されます。
FIDO2の代表的な特徴は、フィッシング耐性です。
WebAuthnでは、認証要求が発生した際に、サービスから送られてくるoriginの値と、その時点でブラウザがアクセスしている値が一致する場合のみ、認証処理が行われます。このため、URLが異なるフィッシングサイトが正規のサービスを模倣しても、ユーザー認証は成功しません。ここではブラウザが介入することでフィッシング耐性が実現されています。
"パスキー"という名前を、多くのかたが目にするようになったのは去年くらいからだと思います。
パスキーという用語にはいくつかの定義がありますが、今回は細かな違いには触れず、GoogleやAppleがブラウザで表示しているように、セキュリティキーを含めたFIDOクレデンシャル全体を“パスキー”と定義して進めていきます。
従来のFIDOクレデンシャルは、セキュリティキーなどのデバイスやPC、モバイル端末のTPM（Trusted Platform Module）に安全に保存され、外部に漏洩することのない、いわゆる“デバイス依存（Device-bounded）”な形態を取っていました。
しかし、Apple、Google、Microsoftがパスキーに対応すると発表したタイミングで、複数のデバイス間で同期されるクレデンシャルというのが出てきました。
AppleではiCloud Keychainが、AndroidではGoogleのパスワードマネージャーが、それぞれパスキーをプラットフォームアカウントと紐付けて管理しています。Microsoftも同様の方針をを考えているでしょう。
ただし、これは完全なクロスプラットフォーム対応というわけではなく、各プラットフォーム内で閉じている点に注意が必要です。
クロスプラットフォームおよびクロスデバイス対応を実現する別のアプローチとして、外部のパスワードマネージャーのパスキー対応が注目を集めています。1Passwordなどの一部のパスワードマネージャーは、ブラウザ拡張機能として動作し、ブラウザ内蔵のパスワードマネージャーが行う処理の前に介入する形で、パスキーのプロバイダーまたは認証器として働きます。
Chromeなどのブラウザに1Password βのブラウザ拡張を導入することで、その動作を確認することが可能です。WebAuthnのAPIを呼び出す際、ブラウザが表示するダイアログよりも先に1Passwordが反応します。最近はAutofillにも対応しています。
特徴として、サービスがユーザーの検証（User Verification）を要求しても1Passwordがアンロックされている場合、ローカル認証は求められません。
このような独特な動作と、ブラウザのダイアログの前に立ち上がってくるということを除いては、ほぼ想像通りに動作すると言えるでしょう。
次に、パスキーのユースケースを紹介します。
まずは、サインインのユースケースから始めます。これまでのパスワード認証に追加されるオプションとして導入が進み、いずれはメインの認証方式として導入されていくでしょう。
既にパスキーに対応しているサービスでは、いくつかの実装パターンがあります。一つずつ紹介していきます。
それでは、例としてYahoo! JAPANのサインインフローをご覧いただきましょう。
ユーザーはログイン画面で、ユーザーの識別子を入力します。その後、サービス側でパスキーの登録状況を確認して、もしパスキーが既に登録されていれば、パスキーによる認証が要求されます。このような認証フローは「Identity Firstパターン」とも呼ばれています。
ここで注意していただきたいのは、パスキーが登録されているというだけで、ユーザーが必ずそのパスキーを使用できるわけではないという点です。
Yahoo! JAPANでは複数の認証方式が設定/利用可能で、エラーが発生した場合にはフォールバックオプションもあります。
しかし、どうしても手間になるので登録時の情報などを使い、パスキーが使える環境なのかを推定する仕組みもあるそうです。
GitHubのログイン画面をみてみましょう。
ユーザーは“Sign-in with a passkey”というボタンを押すことで、パスキーの認証が始まります。
複数のパスキーが利用可能な場合は、ブラウザのダイアログにて利用可能なパスキーの候補から選択を求められます。
ディスプレイネームなどとセットで保存されるクレデンシャルはClient Discoverable Credentialと呼ばれています。
この処理は、認証要求をする前にユーザーを特定していません。
ここでの認証要求は「その環境で使えるパスキーで認証してください」というニュアンスになります。
GitHubは開発者向けのサービスであるため、パスキーについて知っている人も多いと思われます。しかし、一般のユーザーにとっては、パスキーの認知度が十分に高まるまで、このようなボタンを見ても何が行われるかがわからないかもしれません。それどころか、「登録していないのに試しにボタンを押してエラーが出る」という状況も考えられます。
私が関わるMIXI Mでは、Autofillという機能を採用しています。PCのブラウザでの利用の際には、SMS番号やメールアドレスの入力フォームの近くに利用可能なパスキーが表示されます。
モバイル端末のブラウザでは、画面を表示した際や入力フォームにアクセスした瞬間などに、利用可能なパスキーが表示されます。
どちらも、利用したいパスキーを選択するとローカル認証が要求されます。
同じくAutofillを利用しているMoney Forward IDのログイン画面では、PCとモバイル端末のどちらのブラウザでも、利用可能なパスキーに加えて、パスワードの候補も表示されています。
実はGitHubも同様の対応をしています。
ここからわかるとおり、「Autofill」は、パスキーをこれまでのパスワードマネージャーが管理していたパスワードと同じUIで利用できる仕組みです。パスワードからパスキーへの移行を考慮する上でもとても重要な機能です。
MIXI Mでは、端末に直接保存されたパスキーだけでなく、セキュリティキー、モバイル端末に保存されているパスキーも使用することができます。
モバイル端末について、PCのブラウザに生成されたQRコードを読み取ったり、プッシュ通知を介してモバイル端末とPCをBLE（Bluetooth Low Energy）で接続することによって、そのモバイル端末に保存されているパスキーも利用可能です。
これはHybrid Transport、Hybridフローと呼ばれています。
しかし、このHybrid Transportを利用した認証フローが何度も繰り返されると、ユーザーは疲れてしまうでしょう。そのため、Hybrid Transportの利用を検知した際に、その端末上で直接パスキーを生成・登録するように誘導することも重要です。
もう一つの重要なユースケースとして、パスキーを用いた再認証があります。
MIXI Mでは、例えばSMSやメールで一時的な認証コード（OTP）を使ってログインした後、パスキーの管理画面にアクセスする場面では、すでに登録されているパスキーで再認証を求めます。このようにして、比較的弱い認証手段を使った後でも、重要な操作にはより強力な認証を要求することで、セキュリティリスクを低減しています。
GitHubでは、例えばアカウントの重要な設定変更を行う前や一定時間が経過した場合に、再認証が求められます。このとき、GitHubはパスキー認証を最優先とし、それが出来ない場合には、例えばパスワードや二段階認証など、別の認証方法へのフォールバックも用意されています。
再認証の適用例としては、クレデンシャルや個人情報の管理機能、決済機能といった特定の機能の保護に利用できます。他社事例でいうと、メルカリは現在、メルコインというビットコイン関連サービスの保護のためにパスキーを利用しています。
また、これはパスキーに限らずですが、単にログインかログアウトかの二元的な状態だけでなく、より細かく設計されたセッション管理でも再認証が有用です。有効期限を短くしたり、リスクベースの判定と組み合わせたり、他のセッションで重要な操作をしたり、認証レベルの概念を導入したりなど、ログイン状態を保ちつつ必要に応じて再認証を要求できます。
ここまで紹介したサインインや再認証にパスキーを使用する場合、いくつか必要な機能があります。パスキーの管理機能、新規登録時のパスキー登録はもちろん、それだけでなくパスキー登録のプロモーションや、パスワードなど他の認証方式からパスキーへのマイグレーションなども必要になります。パスキーの導入を検討する際には、必要な機能がどれだけあるのか、どこまでやるのかを検討する必要があります。
ここではネイティブアプリにおけるパスキー認証の実装に触れます。
ネイティブアプリでパスキーによる認証を利用する場合、ネイティブ側での実装と、Webアプリとして実装してブラウザで開く、という2つのアプローチが考えられます。
Androidの場合、Googleが提供する開発ドキュメントとUIガイドラインが存在します。これを参考にすることで、Androidアプリにパスキーによる認証を比較的スムーズに導入することができます。特にWebAuthnに関する知識がある開発者であれば、大きな障壁にはならないでしょう。
今回はUIガイドラインの内容を少しピックアップします。
この部分は、サインアップ時にパスキーを登録するフェーズです。ユーザーはまずユーザー名とメールアドレスを入力した後、パスキーの登録に進みます。見た感じ、Webアプリで実装した場合とほぼ同じであることがわかります。
サインインのボタンを選択し、そこからパスキーで認証します。
クレデンシャル管理画面では、登録ボタンの近くにパスキーの概要説明があります。まだパスキーとは何かがわからないユーザーは多いので、説明は大事です。
リカバリーフローも提示されています。
もしパスキーが使用できなくなった場合は、指定したメールアドレスにリカバリーリンクを送信します。そのリンクをクリックすることで、新たなパスキーを登録する手続きができます。
これは、一般的なパスワード再設定のフローをパスキーに適用した形と言えるでしょう。
一方で、Webアプリとネイティブアプリの両方でサービスを提供する場合、ブラウザを活用することで認証機能の開発や運用にかかる工数を削減することが可能です。
ただし、パスキーが利用可能かどうかはブラウザのサポート状況に依存する点に注意が必要です。
ご覧いただいた通り、どちらの手法が機能的に優れているわけではありません。
提供するアプリの種類や開発者のスキルセットに応じて、最適な選択をする必要があります。
パスキーのUXの課題について説明します。
パスワードレス用途でパスキーを登録する際、認証時と同様にUserVerification、つまりローカル認証が要求されます。
単一の要求では気にならないかもしれませんが、例えばパスワード認証からのマイグレーションではパスワード認証に続いてローカル認証を要求され、ユーザーにとってストレスになる可能性もあるでしょう。
ちなみにAndroid端末にGoogleアカウントでログインすると、そのAndroid端末には自動でパスキーが生成され、Googleにも登録されるようです。一般的なRPでもこのようにシームレスな登録ができると導入が進むでしょう。
RPがパスキーのリストを指定して認証要求を行った際、一部の端末では「利用できるパスキーがありません」というエラーメッセージが表示されることがあります。
このエラーに遭遇したユーザーは、思考が停止する方もいるでしょう。エラーは見せても良いですが、サービス側にフィードバックして、ユーザーをフォールバックやリカバリーの手順に誘導する方が良いと考えています。
認証においてパスキーのみを利用するリカバリー手法について考えると、2つのパスキーを登録する方法も考えられます。しかし、このアプローチは現実的でない場合も多いです。そのため、eKYC（電子顧客認証）やID連携を活用したセルフリカバリーの方策が検討されていくべきだと考えます。
あとは、モバイル端末のパスキーを利用する方法としてHybridフローを紹介しましたが、その逆、つまり新しいモバイル端末にPCのパスキーでログインすることはできません。
クレデンシャル管理においては、サービスと認証器の両方でパスキー情報の更新や削除が行えないため、不具合が生じる可能性があります。例えば、使えなくなったパスキーがAutofillの候補として表示されたり、ユーザー名が古いままであったりすることが起こりえます。
最後にパスキーとID連携について話します。
ソーシャルログイン、またはID連携とも呼ばれるこの方式の特徴を簡単に振り返りたいと思います。
RP（リライング・パーティ）と称されるID連携を活用するサービスは、IdP（アイデンティティ・プロバイダ）から提供されるユーザー情報を用いて、簡潔なアカウント登録を実現できます。
ユーザーがIdPで既にログインしている場合には、シングルサインオン（SSO）と呼ばれる使い勝手の良い認証が可能です。
また、ユーザーの明示的な同意のもとで、IdPからRPへ属性情報を提供できます。
しかし、ID連携にも弱点や欠点が存在します。
1つ目は、どのサービスを利用しているかという情報がIdPやRP間で名寄せできることです。プライバシーに対する懸念を抱いてID連携を避けるユーザーやサービスは存在します。
2つ目は、IdPに障害が起きているや、ユーザー単位でBANされた場合など、IdPの機能が利用できなくなると、ログインできなくなるリスクがあります。
3つ目は、RPがIdPに対して再認証を要求することは仕様で定義されているにも関わらず、多くのコンシューマ向けIdPではこの機能が実装されていません。
これらの問題を考慮して、一部のRPはID連携を使用しながらも、ユーザーにパスワードを設定させることで、ID連携が利用できない状況に対するフォールバックや再認証機能を提供しています。
ID連携を利用しない、または利用したくないサービスにおいても、パスキーの採用により、IdPと同等の安全性と利便性を持つ認証機能を実現できます。ID連携を行わないため、名寄せによるプライバシーのリスクも存在しません。
IdPがパスキーを利用する場合のメリットは主に2点に集約されます。
最近、あるサービスから漏洩したパスワード（復号可能な状態で）を用いて、不正ログインが行われたという話題がありました。いわゆる2次被害になるわけですが、それがID連携機能を提供しているIdPとなると困った話になります。ここではそのIdPを仮にXとすると、XとID連携を利用するRPも被害を受ける可能性が出てくるわけです。
このように、IdPのアカウントは非常に価値が高く、パスキーの採用によってこれらのアカウントをより効果的に保護できます。
そして、IdPが提供する認証機能が安全かつ便利であれば、そのIdPと連携するRPもその恩恵を受けることができます。
ID連携を行っているRPがパスキーに対応する場合、ID連携とパスキーの双方の欠点を補完することが可能です。
まずは、ID連携の欠点である「IdPが利用できない状況」や「再認証が必要な場合」において、パスキーを用いることでこれらの問題を効果的に解決できます。
端末の機種変更時やその他の理由でパスキーが利用できない状況が生じた場合、ID連携をリカバリーの手段として活用することもできるでしょう。
AppleやGoogleのようにプラットフォームアカウントにより同期されているパスキーの利用を許可している場合、安全性はプラットフォームアカウントに依存します。
その観点でいうと、プラットフォームアカウントとのID連携をパスキーのリカバリーに利用できます。
このID連携とパスキーの組み合わせに関するアプローチは、今後パスキーのみを認証方式として利用するサービスのリカバリーやフォールバックの課題を解決する方法として議論されていくと思います。
まとめます
パスキーは、システムによるクレデンシャル管理をユーザーに強制する仕組みとして設計されています。安全性と利便性の両立を目指し、クロスデバイスおよびクロスプラットフォームの使用環境も考慮されています。
サインインに関するユースケースでは、既存のサインインUXに適合する形で実装パターンを選択する必要があります。
また、再認証機能を用いることで特定の機能をより安全に保護することが可能です。さらに、細かく考えられたセッション管理にも利用できます。
UXにはいくつかの課題が存在します。
例えば、ストレスフリーな登録フローの実現が求められています。
特に慣れていないユーザーに対しては、エラー画面を表示するよりも、スムーズにフォールバックやリカバリーへ誘導することが重要です。
パスキー管理についても、改善の余地はありそうです。
ID連携において、IdPとRPの両方に、パスキーを利用するメリットが存在します。
IdPは、パスキーによる安全性と利便性を連携先のRPにも共有することができます。
また、サービス側ではID連携とパスキーの組み合わせにより、お互いの弱点を克服できる可能性があります。
以上で私の発表を終わります。
もしパスキーに興味を持たれた方がいましたら、今回の発表で紹介したパスキーが導入されているサービスを実際に利用して、その動作を自身で体験してみてください。
以上です！
Discussion