🐈‍⬛

OpenID Summit Tokyo 2024 でパスキーとID連携について話しました

2024/01/20に公開

Security

こんばんは、ritouです。

タイトルの通り、お話をしてきました。

それではどうぞ。

動画

(2024/4/12: 動画が公開されていたので追記しました)

https://youtu.be/yZ1odRSRgkA

内容

OIDF-Jでエバンジェリストをしています。ritouです。

今日はパスキーとID連携についてお話させていただきます。

この発表では次の3点について話します。

それぞれの特徴/特性
ID連携のIdP/RPそれぞれがパスキー認証をサポートすることで得られるもの
関連するOIDC/OAuth 2.0の仕様

まずはそれぞれの特徴、特性から見ていきます。

パスキー、具体的には「FIDOクレデンシャルを用いた認証方式」について、特徴を振り返ります。
まずは公開鍵暗号を利用すること、ブラウザなどの仲介によるフィッシング耐性による安全性です。
そして、利用者の確認としてローカル認証と呼ばれる画面ロック解除の仕組みを利用すること、各プラットフォームや独立したパスワードマネージャー単位でクレデンシャルを同期することによる利便性があります。

現時点の課題としては、いくら同期の仕組みがあるとは言え、どうしても考慮が必要となるアカウントリカバリー、プラットフォームをまたいだパスキー管理の効率化などがあります。

サービス側の対応フェーズとしては、昨年2023年はパスキーを管理して、サインインに組み込む部分を実装するサービスが出てきました。

今年は新規登録時にパスキーを登録する部分、パスワード認証を行っているユーザーのパスキーへのマイグレーションというところにもフォーカスが当たるでしょう。

一方、ID連携は単純な認証方式としてだけではなく、メールアドレスやSMSの確認状態を用いた身元確認の方法としても利用できる仕組みです。

午前中のパネルにもあったように、10周年を迎えたOpenID Connectはそのシンプルな設計から幅広い環境で利用できますし、OIDFのワーキンググループの活動からみて取れるように様々なユースケースに対して拡張仕様やプロファイルが作られています。

OIDCの仕様策定から10年、課題も見えています。

Webブラウザの基本的な挙動で実現できるシンプルな仕組みだからこそ、その制約を超えるようなUXを実現することが難しい面があります。例えばIdP/RPを跨いだ認証状態の共有を実現するためには3rd Party Cookieの利用などが必要でしたが、最近はブラウザが仲介するFedCMなどでの実現が検討されています。
IdP-RP間、複数RP間での利用状況や属性情報の名寄せを気にするユーザーもいます。
IdPがサービス停止していたりアカウントBANによるトラブルも考慮が必要です。
OIDCで定義されている機能のうち、一部のみ実装されているケースも見られます。IdPが実装していない機能をRPは利用できないのです。

それでは、ID連携のIdPがパスキー認証のサポートについて考えてみましょう。

単純な認証方式としてID連携と比較した際のパスキー認証の優位な点としては

Autofillと呼ばれるブラウザが仲介する仕組み
IdPのサービスではなくパスワードマネージャーを使うことによるプライバシーリスクの軽減
サービスであるIdPよりはコントローラぶるなパスワードマネージャー依存のリスク
UserVerificationを明示的に要求できるため再認証機能が使いやすい

といったものがあります。

これらの特徴から、パスキー認証によって

UX向上
ID連携を嫌がるユーザーへの訴求

という面でID連携の弱点を補うという考え方ができるでしょう。

また、ID連携と組み合わせることでパスキー認証の弱点を補うとも考えられるでしょう。

次に話しますがIdP自体がパスキー認証に対応していたり、リスクベース認証に対応していることを考えると、パスキー認証を加えることで強度の強い認証方式を複数持てると言えます。

また、これからは減ってくると思われますがパスキー非対応環境のサポートとしても有用でしょう。

IdP側の話も少ししましょう。

こちらは割と直感的だと思います。

IdPがパスキー認証に対応し、それをユーザーが利用することでID連携をしているRPを利用する際もその安全性を享受できます。

IdPは他の認証方式を採用していたり、本人確認の仕組みを持っているところが多いです。
これにより、パスキーが使えない状態になってもアカウントリカバリーがしやすく、ユーザーにとっても安心して利用できるでしょう。既にパスキーを実装しているサービスにはIdPとなっているところも多いので、是非使ってみてください。

ここからは、パスキー認証とID連携の組み合わせに関連する仕様を紹介します。

ここで簡単にOpenID Connectの認証フローを振り返ります。

エンドユーザーがSignIn with… というボタンを押して認証フローが始まります
Relying Partyはブラウザのリダイレクトを使ってOpenID Provider(ここまでIdPって言っていたサービスと一緒です)に認証リクエストを送ります。
OPはエンドユーザーにログインさせたり、RPがこんな情報を欲しがっているという要求に対して同意を求める、というインタラクションを行います。
最終的に、OPはRPに認証レスポンスを返します。

ざっくりいうと、こんな感じです。

ここで、OPがパスキー認証をサポートすると、3のユーザーインタラクションのところでパスキー認証が行われます。

RPは認証リクエストに acr_values や、claims というパラメータを指定することで、OPに対して

エンドユーザーにこんな認証強度を要求してください
エンドユーザーの認証強度を教えてください

という要求ができます。このacrはAuthentication Context Refferenceといいます。

そして、OPは認証レスポンス、具体的にはIDトークンにacrやamr(こちらは認証方式であるAuthentication Method Referrence)を含みます。すると、それを受け取ったRPは

エンドユーザーはパスキー認証を行ったこと

を知るわけです。

このあとはRPに自由度がある部分ですが、サービス内容によってある程度の認証強度が必要だというポリシーを定めた場合、パスキーを使わずにパスワード認証のみのエンドユーザーにはサービスを利用させなかったり、追加認証をRPが要求したりできます。

パスキー認証の特徴として、ローカル認証を使った認証をほぼ確実に要求できることがあります。

その特徴を生かすため、RPがOPに「再認証」を要求する方法を紹介します。

先ほどのacr_valuesやclaimsに加え、認証時刻からの経過時間の許容範囲を指定するためのmax_age、対象となるエンドユーザーを指定するためにlogin_hintやid_token_hintという値を指定します
OPは指定されたパラメータを検証しつつエンドユーザーに再認証を要求します
OPは認証レスポンスにacr, amrに加えて認証時刻であるauth_timeというClaimを含みます

こうして、RPはエンドユーザーが再認証を行ったこと、その内容を確認できます。