ニュース
急増するパスキーの利用、導入を促進する機能や“よくある誤解”をOktaが解説
2024年8月7日 06:00
Okta Japan株式会社は6日、パスワードレス認証の手段であるパスキーの状況について説明会を開催した。米Okta アイデンティティスタンダード担当シニアアーキテクトのTim Cappalli氏によると、2024年4月の段階でパスキーを使用しているGoogleアカウント数は4億以上にのぼっているという。
Cappalli氏は、7月末にDashlaneが発表した2024年のパスキーに関するレポートを引用。4月から6月にかけての3カ月間で最もパスキーの利用が増加したのは、88.9％増となったAmazonだったという。パスキーを導入している業界については、Eコマースが全体の41.7％を占め、ソフトウェアサービスが19.9％、金融が14.4％だとしている。
ブラウザのChrome上で実際に生成されたパスキーの数や、パスキーが利用された数も急増しており、「この上昇トレンドは今後もしばらく続くだろう」とCappalli氏は述べている。
このようにパスキーの採用が急増していることから、「Relying Party（ユーザーがサインインするサイトやサービス）が必要とする新技術や機能を次々と実装し、進化していかなくてはならない」とCappalli氏は述べ、その進化を4点紹介した。
1点目は「Feature Detection」だ。これは、ブラウザのページにおいて、パスキーの生成に必要な機能がカバーされているか検出すること。これにより、「開発者はスムーズなログインエクスペリエンスが提供できるようカスタマイズできる」とCappalli氏は説明する。
2点目は、「クライアントのユーザー体験を最適化した」とCappalli氏。過去数年でFIDO Allianceやさまざまな企業が大規模なユーザー調査を行い、その結果を基にパスキーの生成やサインイン時のユーザーインターフェイスが大幅に改善されることになったという。
3点目は「Conditional Creation」で、ユーザーを自動的にパスワードからパスキーにアップグレードする機能だ。これは、ユーザーがパスワードをAutofill（自動入力）した際に、Relying Party側がパスキーを生成するよう促すというもので、「これによりユーザーは、フィッシング耐性のある形でアカウントにアクセスできるようになる」とCappalli氏はいう。
そして4点目は「Related Origins」で、グローバルで事業運営するベンダーが、大規模にパスキーを展開するにあたって重要な機能だ。
「例えば、米国でshopping.comというドメイン名で事業展開し、日本ではshopping.co.jpというドメイン名を採用している事業者は多い。この場合、shopping.comでパスキーを利用していたユーザーが、日本でshopping.co.jpにサインインしようとすると、shopping.comのパスキーが機能しないことがある。その不便さを解消するのがRelated Originsだ」とCappalli氏。
この機能を利用すれば、Relying Partyが他国のカントリーコードドメインでもパスキーが使えるよう指定できるとし、「大規模ベンダーがパスキーをグローバル展開する際にはこのような機能が非常に重要だ」とCappalli氏は述べている。
パスキーに関する誤解を解く
続いてCappalli氏は、パスキーの導入や利用においてよくある誤解を解説した。1点目の誤解は、パスキーが独自仕様だと考えられている点だ。これについてCappalli氏は、「パスキーは、FIDO2／WebAuthnの標準スタックで定義され、使用されるクレデンシャルだ。標準スタックで定義されているため、パスキーを使って複数のデバイスやサイト間で相互運用性が担保されている」とした。
2点目は、パスキーが単なるフェデレーションであるという誤解だ。正しくは、「パスキーはRelying Partyごとにユニークであり、パスキーの提供者とRelying Partyの間には直接的な関係はない」とCappalli氏。フェデレーションの場合は、ユーザーと、サインインしようとするサイトやアカウントの間に直接的な関係があるが、「パスキーの場合、パスキーが保存されている場所とユーザーがサインインしようとしているサイトの間に直接的な関係はない。これがプライバシーを担保するパスキーの特徴だ」という。
3点目の誤解は、パスキーが大手ハイテク企業によるユーザーの囲い込み手段と見られている点だ。これについてCappalli氏は、「ユーザーは好きなパスキープロバイダーを選択できるし、プロバイダー間でパスキーの移行も可能。決してロックインするものではない」と説明する。
4点目は、パスキーがウェブサイトやアプリに個人の生体認証データを提供するのではないかという誤解だ。この点についてCappalli氏は、「生体認証はオプションとしてローカルユーザーの認証に使用できるものであって、その情報をRelying Partyやパスキープロバイダーに送信することは決してない」とした。
パスキーの採用を加速させるには
最後にCappalli氏は、今後さらにパスキー採用を加速させるための提案として、「WebAuthnスタックを自前で開発しないように」と述べた。IDaaSプロバイダーのほとんどが、パスキー機能をネイティブで提供しているためだ。それでも自前で開発したい場合は、「SimpleWebAuthnなどFIDO準拠のライブラリを使用すれば、かなり手間を省くことができる」という。
また、パスキーは、現在パスワードが使用されているサインインの仕組みに追加でき、しかもユーザー体験を変更する必要もないことをCappalli氏は強調。「AutofillのUIを活用し、ユーザーをパスキーになじみやすくしてもらいたい」とした。