パスキー導入検討 (1) 採用スタイルと対応環境

ritou です。

今年2023年、いよいよパスキーが本格的に利用され始めるとお考えの方もいらっしゃるでしょう。果たして「パスワード認証に代わりパスキーが使われ、パスワードレスな時代へと突入する」という予想は現実的なのでしょうか？この記事ではサービスにパスキーを導入するために最初に何を考える必要がありそうかというところから整理していきます。

ここではこれまでパスワード認証やID連携(ソーシャルログイン)を利用してきたサービス、それらと同様の新規サービスあたりを想定しています

パスキーの採用スタイル

「ユーザー認証の方式としてパスキーを採用する」と言っても、いくつかのスタイルがあります。

メインの認証方式として採用
オプショナルな認証方式として採用
採用しないが、採用しているIdPとID連携する

サービスがパスキーの恩恵を受けるために、どのスタイルを採用するかを最初の方で考える必要があるでしょう。

1はまさに「パスワードを置き換える」というイメージに近いかと思います。これが理想な姿であるのでしょうが、これを実現するためにはサービス、アプリが必ずパスキーが動作する環境にある、もしくは対応している端末と接続できるような環境である必要があります。

2は他の認証方式との組み合わせのイメージです。

1を目指す上で徐々に移行
認証強度の高いIdPとのID連携がメイン、それを使いたくない/バックアップ用途としてユーザーが利用

などがこれに当たるかと思います。

1,2のいずれかが採用スタイルになるかと思いますが、あえて3を追加しています。 FIDOアライアンスのセミナーなどではID連携との関連はあまり語られていませんが、ユーザー認証の設計ではID連携も含めて検討する必要があるでしょう。

ID連携機能を提供するIdP
ID連携機能を利用するRP

と言う、ID連携の登場人物それぞれにおいてパスキーを採用するメリットがあります。

IdPがパスキーを採用 : パスキーで保護されたユーザーの情報をRPに利用できる
RPがパスキーを採用 : IdP上のアカウントBANや障害時など、ID連携が利用できない状態のリカバリー手段としてパスキーを利用できる

パスキーの文脈と混乱しがちですが、ID連携の文脈でApple/Google/Microsoftなどプラットフォーマーのアカウントはリスクベース認証や同一プラットフォームに接続されている他の端末を利用した認証機能など、認証強度やアカウントリカバリーの面で優れていると言われています。そのようなプラットフォーマーではないIdPでも、パスキーを採用することでIdPのアカウントがフィッシング耐性を持てるのであれば価値向上につながると言えるでしょう。また、パスキーに対応したIdPがn個のRPと接続している状況ではそのRPのサービスもその恩恵を受けられることになります。

RP側としても上述の強度の高いIdPとID連携している場合、何かあった際のリカバリーのための認証方式としての採用が考えられるでしょう。このようなID連携の話をする場合は "acr" や "amr" などを用いてIdP-RP間で認証強度や認証方式に関する情報までやりとりすべきであると声を大にしてずっとずっと言って来ました。今回のパスキーあたりは良い機会になると思うのでIdPを実装している開発者は考慮していただきたいと思います。

対応環境についての検討

上述の採用スタイルのうち、自分のサービスはどれに当たるのか、これで行きたいと決める際に、対応環境について確認、検討する必要があります。

サービスを提供する環境について対応状況は十分か？
非対応環境での代替手段はあるのか？

昨年末に行われたFIDOアライアンスのセミナーでも、「(サービス名、会社名)はiOSでのパスキーサポートを表明しました！」みたいな発表がありましたよね。例えばiOSアプリのみ提供、OSのバージョンが高く、制限があるAppleアカウントがあまり使わないようなサービスであれば、Appleアカウントによるバックアップが取られている=パスキーがサポートされていることがある程度保証されていると言えるでしょう。

悩むのは非対応環境が様々なレイヤで存在するケースですね。例えばWebアプリケーションの場合、

プラットフォーム
端末(ロック解除方法がどの程度用意されているか)
ブラウザの種類、バージョン(WebAuthn, DiscoverableCredentialsなど)

などで実際使えるユーザーがどれぐらいいるのか、使えるとしてもロック解除を使うUXがまともかどうかというのを検討する必要がありますね。現時点において、メインの認証方式として採用できるような状態にあるサービスはまだ少ないかと思います。今後のパスキーを取り巻く状況の変化によりますが、採用スタイルとしては2を選びつつ、サービスによって1にできるかどうかを引き続き検討していく形になるのかなと思います。