パスキーの導入状況と、よくある「誤解」とは？ - Oktaが解説

Okta Japanは8月6日、パスワードレス認証の手段の1つである「パスキー(Passkey)」の導入に関する最新状況の説明会を開催した。米Okta アイデンティティスタンダード担当シニアアーキテクトのTim Cappalli氏が解説した。

パスキーを考える4つのポイント

冒頭、Cappalli氏は「パスキーはパスワードの代替であり、それに付随するすべてのものの代替だ。時としてパスワードの利用は、フラストレーションがたまることがある。パスキーを考える際には、4つのポイントがある」と述べた。

米Okta アイデンティティスタンダード担当シニアアーキテクトのTim Cappalli氏

その4つのポイントとは「名称」「種類」「アイコン」「機能」だ。名称は例えばディスカバラブルクレデンシャルなどユーザーフレンドリーとは言えないものであり、技術的なスペックを反映していたため馴染みのないものだったという。そのためエンドユーザーにとって馴染みやすいものとして「パスキー」という名称に至った。

種類に関しては、それぞれのニーズ・好みに応じて大別すると単一のデバイスに紐づいたDevice bound passkey、同期型のSynced passkeyの2つが存在。同氏は「Device bound passkeyは高いセキュリティがあるが、一般ユーザーにとっては不便な側面がある。Synced passkeyはさまざまなデバイスで同期することから、デバイスを紛失しても新しいデバイスで代替できるメリットがある」と述べた。

パスキーには2つの種類がある

アイコンについては、見ただけで判断できることは重要ではないかもしれないが、ユーザー視点では重要な意味合いを持つという。ユーザーがアイコンを見ることにより「これを使う」というユーザーエクスペリエンスが期待できるとのことだ。同氏はタッチ決済のアイコンを例として挙げている。

機能では、パスキーをサポートするうえで技術的な仕様としてID・パスワードを入力する「Autofill(自動入力) UI」と、会社の共用PCやネットカフェなど、パスキーが保存されていないデバイスでサービスにサインインする際に、個人保有しているAndroid/iOS/iPadOSのデバイスを利用してサインインする「Cross Device Authentication」の2つがある。

パスキーは「Autofill UI」と「Cross Device Authentication」の機能を持つ

パスキーの採用状況と必要な技術

こうしたポイントを兼ね備えているパスキーだが、採用の状況はどのようになっているのだろうか。

その点に関して、Cappalli氏は「パスキーを使用するGoogleアカウント数は4億以上(2024年4月時点)だ。ショッピングやライドシェア、メッセージング、SNS、決済など大手のサービスがパスキーを採用している」と説明する。

パスワードマネージャーを提供するDashlaneにおける2024年度のパスキーの調査では、3カ月の認証数率はトップのベンダーで88%となっているほか、業種としてはEコマースやソフトウェアサービス、決済関連で7割を占めている。

同氏は「昨年からパスキーの生成数、利用数ともに飛躍的に伸びており、しばらくの間は続く。とはいえ、パスキー自体も新しい技術を実装しかなければならない。セキュリティで保護されたアプリケーションへのアクセスを提供するサーバのRelying Party(RP)のニーズに応える進化が必要だ」と強調する。

RPを平たく言えば、ユーザーがサインインするWebサイトやサービスのことだ。これに必要な技術としてCappalli氏は「Feature Detection」「Client UI Optimizations」「Conditional Creation」「Related Origins」の4つを挙げる。

Relying Party(RP)のニーズに応える4つの機能

Feature Detectionは開発者を支援するための機能であり、ブラウザのページ上でパスキーを利用するうえで必要な機能がカバーされているか否かを検出するものとなる。これにより、開発者はスムーズなログイン体験を構築、カスタマイズすることができるという。

Client UI Optimizationsは、パスキーを生成してサインインするためのUXに直接紐づくUIの改善が肝になる。

Conditional Creationは、ユーザーをパスワードからパスキーにアップグレードさせることを指す。RPにおいてデバイスに対してユーザーがパスワードを自動入力した際に、パスキーを生成するように投げかけることで安全にアカウントにアクセスすることができるとのこと。

Related Originsは、大規模なベンダーは各国のドメインでWebサイトを展開していることをふまえ、パスキーはドメインに紐づいていることから、例えば他国でECサイトを利用しようと試みてもサインインできない可能性がある。そのため、サービス提供者側で異なる国のドメインでも機能するように指定する機能が必要になる。同氏は「大規模なベンダーが大規模にパスキーを展開しようとするときに非常に重要になる機能」という。

パスキーに関する誤解、採用を加速させるには？

ここまでパスキーの概要に加え、今後実装していくべき機能について説明したが、パスキーに関する誤解もあるようだ。Cappalli氏はパスキーにまつわる4つの誤解を紹介した。

1つ目はパスキーは独自仕様であるということ。これは、パスキー自体はFIDO2/WebAuthn標準のスタックで定義されており、使用されるクレデンシャルのうちの1つとなっている。

パスキーはFIDO2/WebAuthn標準のため独自仕様ではない

2つ目は単なるフェデレーションと考えられていることであり、RPごとにユニークであることからパスキーの提供者とRPの間には直接的な関係はないと断じている。

3つ目は大手企業がユーザーを囲い込むための新たな手段に過ぎないということ。この点ついて、正しくはユーザーは好きなパスキープロバイダーを選択し、それらのプロバイダー間でパスキーを移行できるという。

そして、4つ目はWebサイトやアプリに個人の生体認証データを提供しているという誤解。これも、生体認証はオプションとしてローカルユーザー認証に使用することを可能とし、RPまたはパスキープロバイダーに送信されることはないとのことだ。

では、パスキーの採用をどのように加速させていけばいいのだろうか。Cappalli氏は「WebAuthnスタックを自前での開発は推奨しない。ネイティブのパスキー機能をを大半のIDaaS(ID as a Service)プロバイダーが提供しており、もし自前で開発したいのであればFIDOに準拠したSimpleWebAuthnなどのライブラリを使うことが望ましい」と話す。