🤞

パスキー対応における2つの段階と必要な機能

2024/01/28に公開

パスキー対応 という記事を見ると フィッシング耐性があるパスワードレスな世界が来る! と期待を抱き、冷静に考えて パスワードが残ってるうちはリスクは残ってるしフィッシングにもやられるし何にもかわらねぇじゃねーか と遠い目をしてしまう皆さん、こんにちは。

ritou です。

いきなり一気に進むわけがないだろ。ということで、認証を必要とするサービスもユーザーも、パスキーにより理想的な状態となるまでには段階というものがあり、 大人の階段と同じで やるべきことがあります。そのあたりを理解することで、一喜一憂せずにやっていきましょう。

2つの段階

  • 既存の認証方式に加えてパスキーによる認証が利用可能 : 過渡期ってやつでしょうか。イマココ
  • パスキーのみが利用可能 : 我々が望んでいる世界や!

あとはその前の なんもしてない段階 です。
そんなに新しい話でもないでしょう。

段階を進めるために必要な対応

これは去年からの状況を当てはめると理解しやすいでしょう。

パスキー認証未対応 -> 既存の認証方式 + パスキー認証

2023年、いわゆるパスキー対応を始めたサービスが行ったことはなんだったでしょうか?

  • アカウント設定に パスキー管理機能 を追加してログイン方法として利用可能とする
  • ログイン方法にパスキー認証を追加する

この2点を行うことで、パスキー認証でもログインできるようになります。

一部のサービスは頑張って次の段階に進もうとしていますが、まずはここまでが過渡期を迎えるために必要な機能です。

既存の認証方式 + パスキー認証 -> パスキー認証のみ

過渡期である現状から最終段階へと進むために、 パスキー認証のみを利用するユーザーを爆誕させる 必要があります。

  • 新規登録におけるパスキー対応 : アカウントの新規登録時にパスキーを登録させる
  • 例の桶じゃない普通の桶 : 「フィッシング耐性がある別の認証方式」や「別の手段でパスキー管理のリカバリーを行う」ことにより、全体の安全性を整える
  • パスキー認証へのマイグレーション : その状態に向けて既存の認証方式を利用するユーザーにパスキーの登録を促し、他の認証方式の利用を止めさせる

アカウントの新規登録については今年動きがありそうな部分です。
マネフォの人がパスキー登録のUXに期待しています。

https://moneyforward-dev.jp/entry/2023/12/28/100000

2024年にある程度見えてきているゲームチェンジは登録 UX の Autofill 対応でしょう。

この辺りが改善されると、アカウントの新規登録時のパスワード設定相当の部分を置き換えることは比較的容易でしょう。

パスキーが利用できない状況に陥った際、現在は複数の認証方式でログイン可能にしておくことで詰みを回避できます。当然ながらそれの裏返しで、パスキー認証が使えると言ってもフィッシングにやられる可能性がある他の認証方式が残っているということは全体としてフィッシングに弱いということです。

理想的な段階に到達するためには、パスキー認証のみもしくは同等の強度を持つ他の認証方式との併用状態により全体の安全性を整えつつ、詰みの少ない状態を提供する必要があります。

果たして デジタル認証アプリ とやらはそれを担えるのでしょうか?

https://public-comment.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=290310311&Mode=0

また、パスキーのリカバリーの際にどんな手法をとるのかも関係します。この辺りはいつもの話なので省略します。

マイグレーションについては、サービスが認証直後などに利用を促すなどのアイディアがあるものの、実際にやってみるとユーザーに「パスキー設定しろって言ってきてウゼェ」とか言われたり、サービス側からも「離脱するからやめて欲しい。せめてうちからの認証フローの時だけは外して欲しい。」とか言われてしまう可能性があります。

サービスよりも少しだけ文句を言われない立場なのがブラウザでしょう。RPが "Passkey Endpoints Well-Known URL" というメタデータ定義を提示しておくことで、それを読み取ったブラウザがパスキー設定していかないか?みたいな誘導を行うような話もあるようです。

https://github.com/ms-id-standards/MSIdentityStandardsExplainers/blob/main/PasskeyEndpointsWellKnownUrl/explainer.md

あとはサービスがいついつまでにパスキー設定しろ。そうしないとログインできなくなるぞ。みたいなキメを行うパターンですが、なかなかこういうのは理解を得られないケースもあるので注意が必要ですね。

ということで、このステップが結構なハードルであり、今年からの頑張りどころと言えるでしょう。

機能単位での必須化という考え方

メルカリはメルコインという機能?サービス?を利用する際にパスキーの登録と再認証を必須としました。

MIXI Mではパスキーが登録されている状態であればそれ以降のパスキー管理にパスキーによる認証を必須としています。何を言ってるかわからない方は↓をどうぞ。

https://zenn.dev/mixi/articles/43068096e7e4dc

アカウント全体をパスキーで保護することは上記のようなステップが必要なわけですが、それの対象範囲を狭めて機能単位でパスキーを必須とする考え方も一つあるかと思います。決済などに関連して本人確認の機能がある場合はCS対応にも利用可能にしておくことでリカバリーに利用可能にできますし、ユーザーのレベルというものを意識した設計というものにも今後注目する必要があるだろうと思います。

まとめ

  • パスキー対応における2つの段階とその間に必要なことを整理しました
  • 去年の動向と、今年からの期待と一致しているところがあるので意識していきましょう
  • アカウント全体だけではなく、特定機能を利用する際の保護、という観点にも注目しましょう

おまけ

XがアメリカのiOSユーザーからパスキーに対応するそうです。

https://gigazine.net/news/20240124-x-passkeys/

Q:
パスキーはパスワードとどう違うのですか?

A:
パスキーはアカウントに関連付けられたオンライン認証情報として機能します。ユーザー名とパスワードを使用してアカウントにログインする代わりに、プライベートパスキーがサーバーにある公開パスキーを使用して自動的にアカウントの認証を行うため、情報の入力を行うことなくログインできます。

なんだこの雑な説明は。今時ChatGPTでももうちょい答えてくれますよ。

ではまた!

Discussion