ritouです。
Digital Identity技術勉強会 #iddance Advent Calendar 2023 シリーズ2の記事です。
諸事情により、来月に行われるOpenID Summit Tokyo 2024で "Passkeys and Identity Federation" っていう発表をすることになりました。
パスキーの登場以来、ID連携、特にソーシャルログインは認証方法として比べられることが多くなりました。この記事では、この2つを比較したりその関係を考察する際に意識しておくべき観点を整理しておきます。
それぞれの特徴
両者は異なる特徴を持っています。
パスキー
用途: 認証
パスキーの管理: プラットフォームが提供するパスワードマネージャー、サードパーティーのパスワードマネージャー、セキュリティキー、ブラウザ
属性情報: 一緒に保持できて引き回せるデータは User Handle ぐらい
ID連携
用途: 新規登録、認証、属性情報の取得/同期
アカウント情報の管理: Identity Provider
属性情報: プロフィール情報、確認済みメールアドレスなどを取得可能なのが一般的
特徴が異なるために、導入箇所や意味合いも異なります。
ざっと思いつくのが
新規登録
ログイン
再認証
ぐらいでしょう。まずは、これらを設計/実装する際に "どちらを選ぶべきか" みたいなところが気になるでしょう。
新規登録
ユーザーの新規登録時にしなければいけない処理がいくつかあります。
身元確認(Identity Proofing)
ログインのためのクレデンシャルを保存
この辺り、細かい話をするためにはIdentity Lifecycleというものを意識しなければならないのですが割愛します。
前者はメールアドレスやSMSの確認が一般的でしょう。これはパスワード認証のリカバリーに利用するイメージが強いですが、ユーザーへの連絡先の確保やSMSを受け取れる=何らかの形でSIMを取得したという条件を利用した大量取得対策など他の目的もあります。これはサービスの内容によって最初から厳重なものを求められたり、不要なものもあったりします。
今年のアドカレでもこの辺りに触れた記事が書かれていました。
後者については、パスワードを設定したりパスキーを登録したりするところです。
パスキーは、前者の機能を提供しません。後者だけです。メールアドレスを確認してパスワードを設定していたサービスがパスキーに対応しても、メールアドレスの確認が不要になることはないでしょう。
ID連携はIdPから受け取った確認済みメールアドレスを信用することにより、前者の代替が可能です。後者について、新規登録したユーザーとIdPから受け取ったユーザーを紐づけることでそれ以降のID連携の際に利用するクレデンシャルを設定させたと捉えることができます。
現状はパスキーによる認証時のUXに注目が集まっていますが、今後は新規登録時のUXについても議論が進んでいくことは容易に想像できます。その時に、サービスの内容による要件が変わることを認識した上で、どのようなフローを実装すべきかを検討する必要があるでしょう。
認証
認証については割とたくさんの考察が行われています。特に注目されているのはこの辺りでしょう。
セキュリティ: 守るべきアカウントやデバイス、リカバリー
UX: 利便性、認証にかかる時間など
前者について、パスキーは認証器のセキュリティの拠り所がポイントとなります。ID連携はIdPとなります(IdPのアカウントが他のIdPの...みたいなのを考えると終わらないので一旦こういう整理です)。パスキーを管理する認証器がプラットフォームアカウントに紐づけられている(iCloudキーチェーン、Googleパスワードマネージャーなどの)場合、依存するのがプラットフォームアカウントとなってID連携でIdPにプラットフォームアカウントを選んだ場合と近づきます。この辺りは自分が書いた記事で少し触れています。
プラットフォームアカウントのBANを恐れる意見も目にします。パスキーの場合はそのような時にデバイスにパスキーが残るかどうか見たいな話もありますが、サービスが複数のパスキーを登録できるようにしておいてユーザーが別プラットフォームのアカウントに紐づけられたパスキーを登録するという手法があります。ID連携でも複数IdPのユーザーとの連携を可能にしておくなどの手法があります。
UXについても気にしている方が多いですね。
圧倒的にパスキーの方が良い！完
IdPにログイン済みだったり、モバイル端末のプラットフォームアカウントの場合、ID連携のフローも結構良い
Passkey Autofill vs FedCM
非対応環境もあるでしょ
細かい比較をここで行うことはしませんが、パスキーの管理状態、IdPのログイン状態ごとのUXを整理しつつ検討を進めるのが良いでしょう。
再認証
サービスによっては実装されていないこともある機能ですが、サービスで扱う情報が高度になったり決済などの重要な機能を扱う場合に再認証機能の実装は重要です。
パスキーでは対象ユーザーに紐づくパスキーによる認証を要求することである程度確実(1Passwordのような独自のUserVerification判定をどう扱うかという話がある)に再認証を実現できます。
ID連携でもOIDCではlogin_hintやprompt、max_ageといったパラメータを用いて対象のユーザーに確実に再認証を要求できる仕様があるものの、実際はサードパーティーアプリケーションには提供されていないなどの状況です。
この辺りの現状から、再認証機能の実装についても今後議論がされていくことになりそうです。
その他、パスキーとID連携の比較
他には、プライバシーの考慮などがあります。DroidKaigiで話しました記事に書きました。
ここまでで、比較を行う際の観点をいくつか挙げました。この手の比較はどっちが優れているかよりも、自分たちのサービスに合っているかという判断が重要になる気がしています。
あとは、組み合わせみたいなところですね。
ID連携のRPがパスキーを実装 : ここまでの話
ID連携のIdPがパスキーを実装 : ここからの話
ID連携のIdPがパスキーを実装するケース
GoogleやY!JとかはID連携のIdPとしての役割があります。そのようなサービスがパスキーを実装する意味は単なる意識高い勢の先行実装ではありません。
IdPが安全な認証方式を実装しているということはRPとしては良いことです。さらに欲を言えば、安全な認証方式をユーザーが選んで実行したことを教えてもらえたらさらに嬉しい。これがよく言われる "acr" や "amr" の話です。
決済サービスなどで必要な認証レベルみたいなのが定義されている場合、
ID連携で認証レベルを満たしているかをやりとりできる(技術面の課題)
ID連携で受け取った認証レベルの値を利用できる仕組みになっている(主に制度面の課題)
というあたりをクリアできると、より安全な状態でサービスを利用できる状態になるのではないかと考えています。この辺りは身元確認の結果の流通のところでも同様でOIDC4IDAで前者の課題をクリアできても後者は犯収法あたりで引っかかるみたいな話がありますね。
まとめ
パスキーとID連携の関係を考える際は、並べて比べてみたり組み合わせ方を考えてみたり、この記事では触れていない技術的な仕様の噛み合わせみたいなところを考える必要があります。この機会に、いろんな観点から検討して時サービスなりに活かせるような流れができたら嬉しいです。
ではまた。