OpenID Summit 2024 (2024-01-19) での@ritou さんの講演のまとめです。
概要:
このドキュメントは、OpenID Summit Tokyo 2024での伊藤氏の発表資料に基づき、パスキーとID連携の関係、それぞれの特徴、相互の補完性、関連する仕様について概説するものである。特に、ID連携におけるパスキーの導入によって得られるメリット、パスキーが苦手とする部分をID連携が補完する可能性、そして関連する技術仕様に焦点を当てる。
主要なテーマ:
- パスキーとID連携の特徴:
- パスキー: 安全性と利便性が特徴。公開鍵暗号方式を採用し、フィッシング耐性が高い。生体認証やパスコードによるローカル認証、パスワードマネージャーによる同期機能により利便性を向上させている。ただし、全端末の紛失やセキュリティキーの紛失といったアカウントリカバリーの課題、プラットフォーム間の同期に関する課題も存在する。
- ID連携 (OpenID Connect): ソーシャルログインとして利用される認証方式。認証だけでなく、メールアドレスの確認や本人確認といったアイデンティティ・プルーフィングにも利用できる。ブラウザの基本的な仕組みを利用しているため、幅広い環境でサポートされる。拡張性が高く、ユースケースに合わせた拡張仕様やプロファイルが策定されている。一方で、ブラウザの制約を超えるUXの実現が難しく、サービス間での認証状態の共有には課題がある。また、名寄せの問題やIDプロバイダーに起因するトラブルも考慮する必要がある。
- “パスキーですけども特徴として安全性と利便性の2つがよく上げられています。まず 公開鍵暗号 を 使った認証方式であると。あとはブラウザーとか仲介するブラウザーが仲介することで 今 までより も他の認証方式とは違うフィッシング 耐性を 持っています。あとは画面 ロックで使われる生態認証だったりパターン認証とかそういうのを使ったローカル認証を使うことで利便性が高いと”
- “OpenID Connectは10周年を迎えましたが、午前中のセッションでも示されたように、基本的なブラウザーの仕組みを利用して実装できるため、サポートされる環境が非常に幅広くなっています。”
2. ID連携におけるパスキーのメリットと相互補完性:
- パスキーがID連携の弱点を補完: UXの向上、ID連携を嫌うユーザーへの普及、セキュリティの強化。ブラウザが仲介する仕組みにより、どのサービスでログインしているか分かりやすくなる。パスワードマネージャーによる管理でプライバシーリスクを軽減。
- ID連携がパスキーの弱点を補完: 非対応環境への対応。IDプロバイダーがパスキーを含む様々な認証方式をサポートすることで、強固な認証基盤を構築できる。パスキー紛失時のアカウントリカバリーのサポート。
- “パスキーが ID連携の弱点を補完するような使い方が考えられます。これにより、ユーザーエクスペリエンス（UX）の向上や、ID連携に抵抗感を持つ人々への対応が可能になります。逆に、ID連携がパスキーの弱点を補強するという側面もあるかもしれません。”
3. 関連する仕様:
- OpenID Connectの拡張: 認証リクエスト時にacr_valuesパラメータを使って認証強度 (パスキー認証の要求など) を指定できる。amrクレームで認証方法を識別できる。再認証が必要な場合にmax_ageパラメータを使用できる。
- OAuth 2.0 Step-up Authentication Challenge Protocol: リソースサーバー (API) がアクセスしてきた認証の強度が不足している場合に、リライイングパーティに再認証を要求する仕組みを提供する。
- 認証リクエストで使用できるパラメーターが定義されています。ACR（Authentication Context Class Reference）は認証コンテキストの参照を意味し、AMR（Authentication Methods Reference）は認証方法の参照を指します。下部の2番目のリクエストを使用すると、特定の認証強度のユーザー、例えば「パスキーによる認証を行ったユーザー」のような具体的な認証方法を指定することができます。
- OAuth 2.0 Step-up Authentication Challenge Protocol（ステップアップ認証チャレンジプロトコル）の例として、以下のようなシナリオが挙げられます。例えば、パスワード認証を行ったユーザーが決済サービスのアプリケーションを利用しようとした際に、そのセキュリティポリシーに合致しないと判断された場合です。
- このような状況では、「ACRの値が不足している」「この認証方法では不十分だ」といった理由で、追加の認証が必要になります。例えば：
- 認証レベルが不足している
- 特定の認証方法が要求される
- 認証から一定期間（この例では3日）経過したため、再認証が必要
- システムは、これらの条件を満たさない場合にエラーを返し、より高いセキュリティレベルの認証を要求することができます。
結論:
パスキーとID連携は、それぞれ異なる特徴を持つが、互いに補完し合うことで、より安全で利便性の高い認証基盤を構築できる。特に、ID連携システムにパスキーを導入することで、UXの向上やセキュリティの強化、非対応環境への対応など、様々なメリットが得られる。開発者は、OpenID Connectの拡張仕様やOAuth 2.0 Step-up Authentication Challenge Protocolなどの関連仕様を理解し、活用することで、パスキーのメリットを最大限に引き出すことが可能となる。convert_to_textソースに変換
はじめに
- 発表者：ritou氏、mixi所属
- テーマ：パスキーとID連携の関係について
パスキーの特徴
- 安全性と利便性の両方を提供
- 公開鍵暗号を使用した認証方式
- ブラウザが仲介することでフィッシング耐性を実現
- 画面ロックに使われる生体認証などを活用
- パスワードマネージャーによるパスキーの同期機能
パスキーの課題
- 同期されたデバイスをすべて失った場合のアカウントリカバリー
- セキュリティキーを紛失した場合の問題
- 異なるエコシステム（Apple、Google、Microsoft）間のクロスプラットフォーム同期の課題
- 真のクロスプラットフォームサポートには外部パスワードマネージャーが必要
パスキー実装の現状
- 2023年：サイトが既存の認証方式に加えてパスキーサポートを追加
- 2024年：パスワードなしで直接パスキーを使用した新規ユーザー登録に焦点
- パスワードからパスキー認証へのマイグレーション戦略が重要に
ID連携（OpenID Connect）の特徴
- OpenID Connectは10周年を迎えた
- 幅広い互換性のために基本的なブラウザメカニズムを使用
- 様々なユースケース向けに拡張機能を開発するワーキンググループによる高い拡張性
- 実装パターンを標準化するためのプロファイル作成
ID連携の課題
- ブラウザの制約によるユーザーエクスペリエンスの限界
- サービス間で認証状態を容易に把握できない（クロスドメインの課題）
- 特定の実装ではサードパーティCookieに依存
- アイデンティティプロバイダーとリライングパーティ間の名前解決の問題
- アイデンティティプロバイダーのサービス停止やアカウント停止のリスク
- OpenID Connect仕様の実装に偏りがある
認証方式の比較
- パスキーはブラウザのオートフィル機能で利用可能な認証情報を表示し、優れたUXを提供
- パスキーを管理するパスワードマネージャーはサービス利用パターンを共有しないためプライバシー面で利点がある
- パスキーは明確な同意メカニズムと再認証のためのユーザー検証を提供
- ID連携システムは実装によっては再認証機能が不足している場合がある
相補的な関係
- パスキーはID連携の弱点を補完できる：
- 改善されたUX
- ID連携を好まないユーザーにアピール
- ID連携はパスキーの弱点を強化できる：
- アイデンティティプロバイダーは複数の認証方法をサポート
- パスキーに対応していない環境でのサポート
- 検証システムを持つアイデンティティプロバイダーはアカウント回復オプションが充実
OpenID Connectの技術的特徴
- 認証コンテキストリファレンス（ACR）値を使用して特定の認証方法をリクエスト可能
- 認証メソッドリファレンス（AMR）パラメータで認証方法を指定可能
- コア仕様には再認証パラメータが含まれる：
- max_age：ユーザー認証からの最大経過時間
- login_hint：正しいユーザーアカウントの特定に役立つ
- id_token_hint：ユーザーの一貫性を確保
高度な機能
- FAPI（Financial-grade API）認証プロファイルはフィッシング耐性とハードウェア保護された認証情報をサポート
- RFC 8176で定義されたAMR値は公開鍵暗号を含む様々な認証方法をサポート
- OAuth 2.0 Step-up認証チャレンジプロトコル（RFC 9470）：
- リソースサーバー（API）にセキュリティ要件を拡張
- 機密性の高い操作に対してより強力な認証を要求するポリシーを可能に
- 不十分な認証強度のリクエストを拒否可能
- セキュリティ要件を満たすための再認証リクエストをサポート
現代のアーキテクチャへの適用
- 内部IAMシステムに適用可能
- アイデンティティプロバイダープラットフォームがSPAやネイティブアプリ（リライングパーティ）を認証
- リソースサーバー（決済サービス、ヘルスケアマイクロサービスなど）が認証要件を強制可能
結論
- パスキーとID連携は異なる特徴を持つが、組み合わせて使用可能
- お互いの弱点を補完できる
- OpenID Connect仕様はすでに安全な認証に必要な多くの機能をサポート
- これらの技術を組み合わせることで、ID連携システムにパスキーのメリットをもたらすことが可能