デジタルアイデンティティ技術 認可・ID連携・認証 応用 / 20250114-OIDF-J-EduWG-TechSWG

2025/01/14 開催
OpenIDファウンデーション・ジャパン デジタルアイデンティティ人材育成推進WG：活動報告会
技術サブワーキンググループ
発表資料

Transcript

1. © OpenID Foundation Japan © OpenID Foundation Japan デジタルアイデンティティ技術 認可・ID連携・認証 応用（修正版） 一般社団法人 OpenID ファウンデーション・ジャパン デジタルアイデンティティ人材育成推進ワーキンググループ 技術サブワーキンググループ 2025年1月14日
2. © OpenID Foundation Japan 技術サブワーキンググループ 2 目的 活動 活動報告会 より多くのデジタルアイデンティティに携わる技術者に ID技術を理解してもら うことを目指します。 初学者中心の WGメンバーが、調査やディスカッションを通じて仕様の理解 を深めています。 初学者が標準仕様を読んで理解に至るまでに必要な概要の解説、ベストプ ラクティス、補足情報を資料としてまとめます。 中間報告会 では、認可・ ID連携の基礎、認証の基礎に関する解説を報告し ました。 今回は応用編としてネイティブアプリの認可、認可・ ID連携のセキュリティ対 策、認証タイプの分類、パスキーの深掘りなどを紹介します。 本日の発表や資料はわかりにく点や誤りも含まれているかもしれませんが、 今後の活動に活かしていきたいため、建設的なご意見とご指摘をお願いします。
3. © OpenID Foundation Japan 【中間報告会資料再掲】目次 1. 登壇者紹介（認可・ ID連携担当） 2. 認可技術の基礎 2.1. 認可とは 2.2. OAuth 2.0 概要 2.3. OAuth 2.0 各 Grant Type 解説 3. ID 連携技術の基礎 3.1. ID 連携とは 3.2. OpenID Connect 1.0 概要 3.3. OpenID Connect 各フロー解説 4. OAuth 2.0 と OpenID Connect のユースケース の分類 4.1. OAuth 2.0 のユースケースの分類 4.2. OpenID Connect のユースケースの分類 4.3. OAuth と OIDC を組み合わせたケースを考える 5. 認可・ID連携のまとめ 3 デジタルアイデンティティ技術 認可・ID連携・認証 基礎 5. 登壇者紹介（認証担当） 6. 認証技術の基礎 6.1. はじめに 6.2. 認証とは 6.3. 認証の仕組み 7. 脅威と対策 8. パスキーの基礎 8.1. パスキーとは 8.2. WebAuthnの仕組み 8.3. 同期パスキーにおける脅威 9. 認証のまとめ 10. 取り組みで感じた課題
4. © OpenID Foundation Japan 【中間報告会資料再掲】目次 1. 登壇者紹介（認可・ ID連携担当） 2. 認可技術の基礎 2.1. 認可とは 2.2. OAuth 2.0 概要 2.3. OAuth 2.0 各 Grant Type 解説 3. ID 連携技術の基礎 3.1. ID 連携とは 3.2. OpenID Connect 1.0 概要 3.3. OpenID Connect 各フロー解説 4. OAuth 2.0 と OpenID Connect のユースケース の分類 4.1. OAuth 2.0 のユースケースの分類 4.2. OpenID Connect のユースケースの分類 4.3. OAuth と OIDC を組み合わせたケースを考える 5. 認可・ID連携のまとめ 4 デジタルアイデンティティ技術 認可・ID連携・認証 基礎 5. 登壇者紹介（認証担当） 6. 認証技術の基礎 6.1. はじめに 6.2. 認証とは 6.3. 認証の仕組み 7. 脅威と対策 8. パスキーの基礎 8.1. パスキーとは 8.2. WebAuthnの仕組み 8.3. 同期パスキーにおける脅威 9. 認証のまとめ 10. 取り組みで感じた課題 認可・ID連携で学んでおくべき OAuth 2.0・OpenID Connectの概要、 ユーザー認証の概念や最新技術であるパスキーの概要を紹介しました。
5. © OpenID Foundation Japan 目次 1. PKCE 1.1. PKCE概要 1.2. 認可コード横取り攻撃とは 1.3. RP実装者のための詳細説明 1.4. OP実装者のための詳細説明 1.5. まとめ 2. メールアドレスをユーザー識別子とするリス ク 3. Access Token の検証と取り扱い 4. OIDCにおけるCSRF 5 デジタルアイデンティティ技術 認可・ID連携・認証 応用 5. 7つの認証器タイプ 5.1. 背景・概要 5.2. 参考文献 5.3. 認証の定義 5.4. AALの定義 5.5. 7つの認証器（フィッシング耐性ある・な し） 5.6. toB, toCでの事例 6. パスキー深掘り 6.1. UX（パスキー作成・認証） 6.2. 実装（パスキー作成・認証）
6. © OpenID Foundation Japan 目次 1. PKCE 1.1. PKCE概要 1.2. 認可コード横取り攻撃とは 1.3. RP実装者のための詳細説明 1.4. OP実装者のための詳細説明 1.5. まとめ 2. メールアドレスをユーザー識別子とするリス ク 3. Access Token の検証と取り扱い 4. OIDCにおけるCSRF 6 デジタルアイデンティティ技術 認可・ID連携・認証 応用 5. 7つの認証器タイプ 5.1. 背景・概要 5.2. 参考文献 5.3. 認証の定義 5.4. AALの定義 5.5. 7つの認証器（フィッシング耐性ある・な し） 5.6. toB, toCでの事例 6. パスキー深掘り 6.1. UX（パスキー作成・認証） 6.2. 実装（パスキー作成・認証） 今回は、ネイティブアプリや考慮すべきセキュリティ対策、 様々な認証器と業界・領域での利用、パスキーのインターフェースの概要を紹介します。
7. © OpenID Foundation Japan 登壇者紹介 7 関根匠海（ NRIセキュアテクノロジーズ株式会社） 自社開発しているコンシューマ向けの CIAMパッケージ製品の 導入、保守、運用をおこなっています。 宍戸優希（株式会社オプティム） 端末一括管理のサービス(MDM)における開発と保守を行なっ ております。 写真 写真 認可・ID連携担当
8. PKCE 8
9. 本章の目的と想定読者層 本章では、ネイティブアプリケーションのようなOAuth2.0のPublicクライアントに対する、 リソースアクセス制御を実現するユースケースを考える。 本章の目的は、上記のユースケースに対する脅威とその対策方法、特に、認可コード 横取り攻撃とその対策としての PKCE利用の概観を説明することである。 本章の想定読者層は、OAuth2.0アプリケーションにおけるクライアント（RP）やIDプロバ イダ（OP）の開発・運用者である。 本章の読者には、OAuth2.0のAuthorization Code Flowのシーケンスや各パラメータ への基本的な知識、およびOP/RP等の用語理解があることを前提とする。 9 1. PKCE
10. 目次 1. PKCE 1.1. PKCE概要 1.2. 認可コード横取り攻撃とは 1.3. RP実装者のための詳細説明 1.4. OP実装者のための詳細説明 1.5. まとめ 10 1. PKCE
11. 1.1. PKCE概要 11
12. はじめに 12 認可サーバからアクセストークンを発行してもらうために、ネイティブアプリのような Publicクライアントが Authorization Code Grantを利用して認可コードを取得する ケースを考える。 このときPublicクライアントには、「悪意あるクライアントによって認可コードが横取りされ る」という脅威が存在する。 Publicクライアントはアクセストークン要求時にクレデンシャルを認可サーバへ送付でき ないため、認可コードを横取した悪意あるクライアントはアクセストークンを窃取できてし まう。 Authorization Code Grant利用時のリクエストに PKCE（Proof Key for Code Exchange）を含めることで、この脅威を軽減 することができる。 1.1. PKCE概要
13. OAuth2.0のクライアントタイプ 13 OAuth2.0には2種類のクライアントタイプが存在する。 1.1. PKCE概要 Client Type 概要 例 Confidential クレデンシャルの機密性を維持することができるクラ イアント、または他の手段を使用したセキュアなクライ アント認証ができるクライアント • クライアントクレデンシャルへのアクセスが制 限されたセキュアサーバー上に実装されたク ライアント Public クライアントクレデンシャルの機密性を維持すること ができず、かつ他の手段を使用したセキュアなクライ アント認証もできないクライアント • ネイティブアプリケーション • SPA（Single Page Application） 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
14. Confidentialクライアントによる PKCE利用 14 OAuth2.0クライアントのPKCE利用について、Publicに対してはMUSTだが, Confidentialに対してもRECOMMENDED (※)とされている。 本資料は、存在する脅威とその対策としてのPKCEの有効性をより簡潔に説明するた め、Publicクライアント、特にネイティブアプリが PKCEを利用するケース に焦点を当 てる。 1.1. PKCE概要 出典元：OAuth 2.0 Security Best Current Practice (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.1.1) (※) Confidentialクライアントの場合、トークン要求時に client_secretを必要とするため、Publicクライアントに比べて認 可コード横取り攻撃の難易度が高くなる。一方、 PKCEは認可コード横取り攻撃に限らず、認可コードインジェクション や、高度なCSRF攻撃（攻撃者がstate値を特定するケース）にも有効とされている。以上のことを踏まえて、 Confidentialクライアントに対してはPKCEの利用はRECOMMENDEDである考えられる。
15. RFC7636 策定までの略歴 15 2007年以降のスマートフォン・ネイティブアプリの普及に伴い、 2013年07月にdraft-sakimura-oauth-tcseが開始。 draft-ietf-oauth-spopへの移行期間を経て、2015年09月にRFC7636として正式に策定された。 1.1. PKCE概要 スマホ・ネイティブアプリの普及 2007 米国iPhone発売開始 2013 日本スマホ普及率約 60% 2008 App Store, Android Marke(現Google Play)でネイティブアプリ誕生 出典元：Datatracker (https://datatracker.ietf.org/doc/rfc7636/history/) draft-sakimura-oauth-tcse draft-ietf-oauth-spo RFC7636 2013/07 2014/08 2015/09 RFC7636策定までの略歴
16. PKCEとは 16 PKCE（Proof Key for Code Exchange）は クライアントが認可サーバへ認可コードを送信してアクセストークンに交換するときに、 送信者自身がAuthorization Code Grantによって認可コードを取得したクライアントであ ること（認可コードを横取した別のクライアントではないこと）を証明するためのProof Key PKCEを利用しないと 認可サーバは、送信された認可コードが「誰が発行した」ものなのかわからない クライアントは、悪意あるクライアントに認可コードを横取りされたとき 、悪意あるクライ アントにアクセストークンが渡ってしまうことを防ぐことができない 1.1. PKCE概要
17. PKCEが無いと... 17 1.1. PKCE概要 ユーザーは、印刷アプリでスマホ標準写真アプリ（ネイティブアプリ）上にある写真を印刷をしたい。 印刷アプリは写真アプリにアクセスするために、ユーザーへの許可を求めた。 ①写真アプリにアクセスす る権限をください ②印刷サービスにアクセスする権限を 与えていいですか 印刷アプリ ユーザー 写真アプリ 認可サーバ(OS) スマホ 悪意のある アプリ 印刷アプリの偽サイト からユーザーにインス トールさせたぜ
18. PKCEが無いと... 18 1.1. PKCE概要 ユーザーのスマホには悪意のあるアプリがインストールされていた。 ユーザーが印刷アプリに許可を与えると、認可サーバ（スマホ OS）は意図せず悪意のあるアプリ（印刷アプリと 同じカスタムURIスキーマを設定している。詳細は後述。）にアクセス権を付与した。 ③アプリに権限を与えてもいいですよ 印刷アプリ ユーザー 写真アプリ スマホ 悪意のある アプリ ④アクセス権を付与します アクセス権 印刷アプリと同じカスタ ムURIスキーマを設定 したので、アクセス権を 取得できた 認可サーバ (スマホOS) ✖ 正規のアプリはアクセス権 を取得できなかった （※）悪意のあるアプリのインストール経路は、フィッシングサイトや公式アプリストアの脆弱性、非正規のインストールサイトなどが挙げられる。
19. PKCEが無いと... 19 1.1. PKCE概要 結果としてユーザの意図とは異なり、悪意のあるアプリが写真アプリへのアクセス権を不正に入手し、写真デー タを取得してしまった。 印刷アプリ ユーザー 写真アプリ 認可サーバ (スマホOS) スマホ 悪意のある アプリ アクセス権 ⑤社員アプリにアクセスする権限もらったので、写 真データください 写真データ ⑥どうぞ
20. PKCEを利用すると 20 1.1. PKCE概要 印刷アプリがPKCEを利用すると、印刷アプリは Proof Keyを作成し、写真アプリへのアクセス権を認可サーバ に要求するときに一緒に Proof Keyを送信する。 認可サーバは受け取った Proof Keyを保存し、ユーザーにアクセス許可を求める。 ①’写真アプリにアクセス する権限をください。 ProofKeyも送ります ③’印刷サービスにアクセスする権限を 与えていいですか 印刷アプリ ユーザー 写真アプリ 認可サーバ(OS) スマホ 悪意のある アプリ ②’ProofKeyを保存します
21. PKCEを利用すると 21 1.1. PKCE概要 ユーザーからアクセス許可をもらうと、認可サーバはアクセス権を印刷アプリに渡す。 悪意のあるアプリは Proof Keyを知らないので、アクセス権を認可サーバに求めても拒否される。 ④’アプリに権限を与えてもいいですよ 印刷アプリ ユーザー 写真アプリ 認可サーバ (スマホOS) スマホ 悪意のある アプリ Proof Keyがわからな いからアクセス権をもら えなかった 💦 ⑤’アクセス権を付与しない ✖ アプリが Proof Keyを 持ってないのでアクセス 権は渡さない！
22. 1.2. 認可コードを横取り攻撃とは 22
23. 認可コード横取り攻撃の攻撃経路 23 (1) ユーザのスマホにインストールされたOAuth2.0の正規のアプリは、Authorization Code GrantによってOSに認可リクエストする。 (2) アプリからの要求を受けて、OSは認可サーバにAuthorization Code Grantによって認 可リクエストする。 (3) 認可サーバはOSに認可コードを返却する。 (4) 攻撃者は、スマホに事前に悪意のあるアプリを登録させている。悪意のあるアプリに は、正規のアプリと同じカスタムURIスキームが登録されている。OSはカスタムURIス キームを確認して、正規アプリと悪意のあるアプリのいずれか（※）に認可コードを返却 する。今回のケースでは、悪意のあるアプリが認可コードを横取りする。 (5) 悪意のあるアプリは、認可サーバに対してトークン要求をおこなう。このとき、(4)で横取 した認可コードを利用する。 (6) 認可サーバは、トークン要求元のアプリが正規のアプリかを確認する術がないので、 正しい認可コードが送信されればアクセストークンを返却する。結果、悪意のあるアプ リは本来正規アプリが取得するはずのアクセストークンを窃取することに成功した。 （※）どちらのアプリに認可コードが返却されるかはOSによって異なる 1.2. 認可コードを横取り攻撃とは：ポンチ図の説明 出典元：RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients (https://tex2e.github.io/rfc-translater/html/rfc7636.html) (3)’ Save Proof Key (6)’ Check Proof Key
24. PKCEにより攻撃を防ぐ方法 24 (1) ユーザのスマホにインストールされたOAuth2.0の正規のアプリは、Authorization Code GrantによってOSに認可リクエストする。この時正規のアプリは、事前に Proof Keyを生成し、認可リクエスト時に Proof Keyを一緒にOSへ送信する。 (2) アプリからの要求を受けて、OSは認可サーバにAuthorization Code Grantによって 認可リクエストする。このときProof Keyを一緒に送信する。 (3) 認可サーバはOSに認可コードを返却し、受取ったProof Keyを保存する。 (4) 攻撃者は、スマホに事前に悪意のあるアプリを登録させている。悪意のあるアプリに は、正規のアプリと同じカスタムURIスキーマが登録されている。OSはカスタムURIス キーマを確認して、正規アプリと悪意のあるアプリのいずれかに認可コードを返却す る。今回のケースでは、悪意のあるアプリが認可コードを横取りする。 (5) 悪意のあるアプリは、認可サーバに対してトークン要求をおこなう。このとき、(4)で横 取した認可コードを利用する。しかし、悪意のあるアプリは Proof Keyの値を知らな いため、認可サーバに正しい Proof Keyを送ることはできない。 (6) 認可サーバは、受取ったProof Keyによって要求は正規のアプリかを確認する。今 回悪意のあるアプリは正しい Proof Keyを認可サーバに送信していないため、認可 サーバは悪意のあるアプリにアクセストークンを返さない。 1.2. 認可コードを横取り攻撃とは：ポンチ図の説明 Proof Key (3)’ Save Proof Key (6) Error (6)’ Check Proof Key 出典元：RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients (https://tex2e.github.io/rfc-translater/html/rfc7636.html)
25. ▪カスタムURIスキームとは 特定のネイティブアプリを起動するための特別なURI。 アプリケーション間通信や特定のアクションをトリガーするため に使う。 「https」というTLS通信用のURIスキームではなく、アプリ固有の文字列（例: myapp）を URIスキームとして利用することで、myappアプリを起動できる。 カスタムURIスキームを使った攻撃シナリオ 1/3 25 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 カスタムURIスキーム パラメータ付きのアプリ上の画面パス 【例】 myapp://open?screen=callback
26. カスタムURIスキームを使った攻撃シナリオ 2/3 26 ▪認可コード横取攻撃が成立する条件 • 正当なアプリはカスタムURIスキームを設定している ◦ 例: print-app://oauth2redirect (※) • 悪意あるアプリは正当なアプリと同じカスタムURIスキームを設定している • 正当なアプリ（RP）は認可リクエストのredirect_uriパラメータにカスタムURIスキー マを指定するが、PKCEパラメータは利用しない。 • PublicクライアントであるRPに対して、OPはPKCE利用を強制していない 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 (※) そもそも「print-app」のように、組織のドメインを主張するのが難しく、他のアプリとの重複可 能性が高いスキーム名を使うべきではない（SHOULD NOT） 参考: RFC 7595 - Guidelines and Registration Procedures for URI Schemes https://tex2e.github.io/rfc-translater/html/rfc7595.html#3-8--Scheme-Name-Considerations
27. カスタムURIスキームを使った攻撃シナリオ 3/3 27 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 印刷アプリと同じカスタム URIスキームを設定した悪意のあるアプリは、 印刷アプリ →認可サーバへの認可リク エストの応答から認可コードを横取できる （※）。 ①アプリに権限を与えてもいいですよ 印刷アプリ ユーザー 写真アプリ 認可サーバ (スマホOS) スマホ 悪意のある アプリ ②認可コードを渡します 認可コード 印刷アプリと同じカスタ ムURIスキーマを設定 したので、認可コードを 横取りできた 認可リクエストに対するユーザーから の同意を得たので、 redirect_uri に設 定された print-app://oauth2redirect に認可コードを返却しよう カスタム URIスキーム 　print-app://oauth2redirect （※）認可コードを悪意のあるアプリが横取するための条件は、アプリがインストールされた端末の OSによって異なる。 ✖ 正規のアプリは認可コード を取得できなかった
28. 利用する端末の OSに応じて、（正規のアプリと同じカスタム URIスキームを設定した） 悪意のあるアプリケーションに認可コードが渡るまでの動作が異なる。 OSによる認可コード横取り方法の違い 28 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 OS 動作 iOS アプリのインストールについて後勝ち方式で認可コードの返却先が変わる 。 具体的には、悪意あるアプリを正規のアプリより後にインストールすると、それ以降はカスタムURIスキームにアク セスするたびに悪意のあるアプリに認可コードが渡る。 Android ユーザが悪意のあるアプリをリダイレクトとして選択すると認可コードが悪意のあるアプリに渡る 。 具体的には、悪意のあるアプリをインストールした状態で、カスタムURIスキーマにアクセスし、OSが表示するポッ プアップ上でアクセス先のアプリとして（正規のアプリが表示されているにもかかわらず）悪意のあるアプリを選択す ると、認可コードが悪意のあるアプリに渡る。 （参考）iOS, Androidそれぞれの認可コード横取のフローは以下に掲載された動画がわかりやすい https://akaki.io/2021/url_scheme_hijack#fn7
29. 1.3. RP実装者のための詳細説明 29
30. PKCEを利用して認可コード横取り攻撃を防御するためには、RPは以下のパラメータを 各OAuth2.0リクエストのパラメータに付与する必要がある。 PKCEパラメータ 30 1.3. RP実装者のための詳細説明： PKCE利用のために パラメータ 必 須 対応API パラメータの役割 OAuth2.0リクエスト上での定義 code_verifier ◦ 認可リクエス ト 以前のページで “Proof Key” と呼 んでいたもの クライアントが生成する 43~128文字のランダム文字列 code_challenge ◦ 認可リクエス ト Proof Keyを右記の方法で変換し たチャレンジ値 code_challenge_methodに応じて以下のように変換する plane（NOT RECOMMENDED） 　code_challenge = code_verifier S256 （RECOMMENDED） 　code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) code_challenge_method - トークンリク エスト Proof Keyをチャレンジ値に変換 するメソッド code_verifierの変換メソッドとして “plane” or “S256” を指定す る “S256” を指定したい場合は利用必須 パラメータを利用しない場合は “plane” として扱われる
31. RPに求められる PKCE利用要件 31 1.3. RP実装者のための詳細説明： PKCE利用のために 利用要件 概要 code_verifierを生成 • （MUST）RPはランダムで推測困難な43〜128文字のcode_verifierを生成 し、後に正当性を証明するために使用する。 code_verifierから code_challengeを生成 • （MUST）RPは生成したcode_verifierをSHA-256でハッシュ化し、 code_challengeを作成する。 認可リクエストにcode_challenge を含める • （MUST）RPは認可リクエスト時にcode_challengeをOPに送信し、OPが保存 する。 トークンリクエストの送信 • （MUST）RPはトークンリクエスト時にcode_verifierをOPに送信し、保存した code_challengeと照合する。
32. シーケンスの登場人物 32 1.3. RP実装者のための詳細説明：シーケンス解説 登場人物 概要 ユーザー ネイティブアプリケーションの利用者。スマートフォン端末を所有している。 クライアント（RP） ユーザーが利用しようとしている正規のネイティブアプリケーション。利用者のスマートフォンにイ ンストールされている。 悪意のあるアプリ 正規のネイティブアプリケーションに酷似した不正なネイティブアプリケーション。正規のアプリ ケーションと同じカスタムURIスキームが設定されている。利用者のスマートフォンに何らかの方 法で不正にインストールされている。 認可サーバー（OP） 利用者のスマートフォンに搭載されたOSの一機能としてネイティブアプリケーションが呼び出すこ とができる認可サーバー。
33. アクセストークンが横取りされるシーケンス例 33 1.3. RP実装者のための詳細説明：シーケンス解説 OPは、認可リクエストに設定されたリダイレクト URI が正当なものかどうかを確認できないので、認可 コードは悪意のあるアプリに横取されうる。 PKCE無しの場合、認可コードの送信元のアプリの 正当性を OPが検証することができないので 、アク セストークンが悪意のあるアプリに横取りされうる。
34. PKCEでアクセストークンの横取りを防ぐシーケンス例 34 1.3. RP実装者のための詳細説明：シーケンス解説 RPが認可リクエストを開始した際に OPで検証を行う ためのcode_challengeの元データとして code_verifierを生成する。 code_verifierをもとにRPがハッシュ化した code_challengeを生成する。 RPはリクエストパラメータに code_challengeを付与 して認可リクエストを送信する。 悪意のあるアプリに認可コードを横取されても、 悪 意のアプリは code_verifierの値を知らないため 、 トークンリクエストによるアクセストークンの窃取を防 ぐことができる。
35. PKCEを導入した認可リクエスト 35 ◼code_verifierの生成について • クライアントは推測が困難なcode_verifierを生成する ◦ 使用される文字：[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" ◦ 最小43文字、最大 128文字で構成される • code_verifierの形式は以下のように定義されている 1.3. RP実装者のための詳細説明：シーケンス解説
36. PKCEを導入した認可リクエスト 36 ◼code_challengeの生成について • クライアントは、生成したcode_verifierから「code_challenge」を作成する ◦ S256方式（RECOMMENDED） ▪ SHA-256ハッシュアルゴリズムを使い、 code_verifierをハッシュ化し、base64url形式にエン コードしたcode_challengeを生成する ◦ plane方式（NOT RECOMMENDED※） ▪ この方式ではcode_challengeはcode_verifierと同じ文字列になる 1.3. RP実装者のための詳細説明：シーケンス解説 (※)NOT RECOMMENDEDである理由は後述
37. セキュリティ上の考慮ポイント 37 1.3. RP実装者のための詳細説明：セキュリティ上の考慮ポイント 考慮ポイント 概要 code_verifierのエントロピー ・（MUST）code_verifierは十分ランダム性を持ち、推測が困難である必要がある。 ・（SHOULD）推測されにくいcode_verifierを生成することで、セキュリティが強化される。 code_challengeのハッシュ化 ・（SHOULD）code_challengeをSHA-256でハッシュ化することで、同じcode_verifierから 同じcode_challengeが生成されるリスクを減らす。 ・（SHOULD）リプレイ攻撃のリスクを低減するために重要。 OAuth全体のセキュリティ考慮 ・（SHOULD）トークンの保管方法や有効期限の短縮、認可リクエストとトークンリクエストの HTTPSによる暗号化、スコープの最小化など、フロー全体でトークンの安全な取り扱いを徹 底する必要がある。
38. 実装アンチパターン 38 1.3. RP実装者のための詳細説明：実装アンチパターン アンチパターン 概要 短すぎるcode_verifier ・（MUST）code_verifierが予測/特定される可能性がある。 code_challengeをハッシュ化しない ・（SHOULD）code_challengeを平文で送信すると、攻撃者がcode_verifierを容易 に取得できてしまう。 HTTPSを使用しない通信 ・（SHOULD）RPからのリクエストをHTTPで送信すると、暗号化されずに認証が盗 聴される可能性がある。 code_verifierの再利用 ・（SHOULD）一度使用したcode_verifierを再利用すると、リプレイ攻撃のリスクが ある。
39. 1.4. OP実装者のための詳細説明 39
40. OPに求められる PKCE利用要件 40 1.4. OP実装者のための詳細説明： PKCE利用のために 利用要件 概要 S256への対応 • （MTI: Mandatory to Implement）RPがcode_challenge_method=S256を指定できる （=code_verifierをS256方式で変換できる）場合、OP側もS256による変換機能を実装してお く。 PKCEパラメータと認可 コードの紐づけ管理 • （MUST）RPから送付されたcode_challengeとcode_challenge_methodについて、OPは自 身が発行する認可コードと関連付けておき、後のトークンリクエストの時に検証できるようにす る。 PKCEパラメータ不備に 対するエラー応答 • （MUST）OPがRPに対してPKCE利用を強制するとき、RPがcode_challengeを送付しなけ れば、OPは認可エラー応答を返す。 code_verifierの検証 • （MUST）OPはアクセストークン返却前に、code_challenge_methodにしたがってRPから送 付されたcode_verifierを検証する。
41. PKCEを導入した認可リクエスト 41 1.4. OP実装者のための詳細説明：シーケンス解説 code_challengeとcode_challenge_methodを確認 し、他のパラメータと併せて管理する。 以下のいずれかの方法で PKCEパラメータと認可コー ドを紐づける。 • code_verifierとcode_challenge_methodを （他のエンティティが抽出不可能な形式で ） 暗号化して認可コード自身に埋め込む • サーバ側で認可コードと紐づけて保存する トークンリクエストで受取った code_verifierと③で受け 取ったcode_challenge_methodからcode_challenge を算出し、③で受取った code_challengeの値と照合す る。
42. 1.5. まとめ 42
43. 脅威と対策のまとめ 43 • ネイティブアプリのようなOAuth2.0のPublicクライアントには、悪意のあるアプリに よる認可コード横取り攻撃という脅威 が存在する。 • 攻撃への対策として PKCEを利用できる。PKCE利用時には、OAuth2.0リクエスト においてOP, RP双方が以下の要件を満たす必要がある。 ◦ 認可リクエスト ▪ RPはOPにPKCEパラメータ①（code_challenge, code_challenge_method）を送付する ▪ OPはRPからのPKCEパラメータ①を認可コードに紐づけて管理する ◦ トークンリクエスト ▪ RPはOPにPKCEパラメータ②（code_verifier）を送付する ▪ OPはRPからのPKCEパラメータ①②を利用して RPの正当性を検証する • PKCEを正しく利用することで、仮に悪意のあるアプリに認可コードを横取されて も、アクセストークンの窃取を防ぐことができる ようになる。 1.5. まとめ
44. RP責任者が意識すべきこと 44 • code_verifierの生成と管理 ◦ ランダムな文字列を使用してcode_verifierを生成していること • code_challengeの生成 ◦ code_verifierをSHA-256でハッシュ化してcode_verifierを生成していること ◦ S256で作成するのはクライアント側で実装すること • 認可コードと code_verifierのトークンリクエスト ◦ 認可コードと一緒にcode_verifierをトークンリクエストに含めていること 1.5. まとめ
45. OP責任者が意識すべきこと 45 • code_challengeの保存 ◦ 認可リクエスト送信時にcode_challengeを認可サーバーで保存されていること ◦ この時、外部から不正アクセスなどができないような状態になっていること • code_verifierとcode_challengeの検証 ◦ トークンリクエスト送信時にcode_verifierを保存されたcode_challengeと照合していること ◦ この時、一致していない場合はトークンを発行しないこと ◦ エラーハンドリングでリクエストを拒否することも検討する • 認可コードのライフサイクル管理 ◦ 認可コードの期限などを短く設定し、再利用されないような管理状態にすること • サイトのセキュリティ ◦ 全ての通信がHTTPSで行われており、code_verifierと認可コードが傍受されないこと 1.5. まとめ
46. © OpenID Foundation Japan 登壇者紹介 46 吉村 拓眞 （株式会社オプティム） 私自身が ID 初学者ですので、初学者なりの視点で、初学者 の方に伝わるよう説明を考えました。 同じくこれから ID を学ぶみなさま、一緒に頑張っていきましょ う！ 認可・ID連携担当
47. メールアドレスを ユーザー識別子として使用するリスク 47
48. • メールアドレスをユーザー識別子とする、とは • どのようなリスクに繋がるか • ユーザー識別子として適切なものは何か 目次 48 メールアドレスをユーザー識別子として使用するリスク
49. 振り返り： OpenID Connect による ID 連携 49 メールアドレスをユーザー識別子として使用するリスク POINT：OP から RP に認証済みユーザーの情報が含まれた ID トークンを渡す エンドユーザーの認証に関する 情報を含む
50. メールアドレスをユーザー識別子とする、とは 1/3 50 メールアドレスをユーザー識別子として使用するリスク メールアドレスでログインできる OpenID Provider との ID 連携を考える
51. メールアドレスをユーザー識別子とする、とは 2/3 51 メールアドレスをユーザー識別子として使用するリスク 悪い例：ID Token の email Claim のメールアドレスを識別子に利用
52. 良い例：ID Token の sub Claim のユーザー識別子を利用 メールアドレスをユーザー識別子とする、とは 3/3 52 メールアドレスをユーザー識別子として使用するリスク
53. • メールアドレスの所有者が別の人になっている可能性がある • メールアドレスの所有者が確認されていない可能性がある • OP 側でメールアドレスが変更されたことを RP 側で検知できない • RP 側にメールアドレスを隠すことができない 考えられるリスク 53 メールアドレスをユーザー識別子として使用するリスク
54. メールアドレスの所有者が別の人になっている 1/3 54 メールアドレスをユーザー識別子として使用するリスク Example アプリは「user-1@hoge.com のユーザー」と認識する
55. メールアドレスの所有者が別の人になっている 2/3 55 メールアドレスをユーザー識別子として使用するリスク user-1@hoge.com の所持者が退会し、別の人がそのアドレスを取得
56. メールアドレスの所有者が別の人になっている 3/3 56 メールアドレスをユーザー識別子として使用するリスク Example アプリは A さんと B さんを区別できない
57. • メールアドレスの所有者が別の人になっている可能性がある ◦ 異なる人の情報を結びつけてしまい、情報の漏洩などが起こりうる ◦ メールアドレスの再利用（他者による再取得）が可能な場合にのみ発生 ◦ 他者による再取得が可能かは、利用しているメールサービスによって異なる • メールアドレスの所有者が確認されていない可能性がある ◦ 他人のメールアドレスを利用し、意図的に他人のユーザーとしてログインできうる ◦ メールアドレスの再利用（他者による再取得）ができない場合でも発生 • OP 側でメールアドレスが変更されたことを RP 側で検知できない ◦ メールアドレスを変更すると異なるユーザーとして扱われてしまう • RP 側にメールアドレスを隠すことができない ◦ 他のサービスの利用状況と紐付けられてしまう ◦ 迷惑メールの送信に利用される ◦ email の scope を許可しなくても連携されるため、ユーザーの同意の範囲外で連携されうる 考えられるリスク 1/2 57 メールアドレスをユーザー識別子として使用するリスク
58. • メールアドレスの所有者が別の人になっている可能性がある • メールアドレスの所有者が確認されていない可能性がある • OP 側でメールアドレスが変更されたことを RP 側で検知できない • RP 側にメールアドレスを隠すことができない メールアドレスだけでなく、電話番号でも同じことが言える （電話番号の場合、再利用・再取得される可能性がより高い） 考えられるリスク 2/2 58 メールアドレスをユーザー識別子として使用するリスク
59. Relying Party 側 • ID Token, UserInfo で得たメールアドレスをユーザー識別子として扱わない • ここで得られるメールアドレスは、あくまで属性情報であることに注意 OpenID Provider 側 • ID Token の sub (= ユーザー識別子) にメールアドレスを用いない • 一意かつ、変化せず、再割り当てされないような値を用いる 実装者の立場で意識すべきこと 59 メールアドレスをユーザー識別子として使用するリスク
60. ID Token の sub Claim の仕様 • 特定の Issuer 内でローカルに一意かつ決して再割り当てされない値でなければな らない (MUST) • ASCII で255文字を超えてはならない (MUST NOT) • 大文字小文字を区別する OpenID Connect が定める技術仕様 60 メールアドレスをユーザー識別子として使用するリスク 参考：「Final: OpenID Connect Core 1.0 incorporating errata set 1」 　https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#IDToken 　https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#ClaimStability
61. sub 以外の Claim について • 長期的な安定性やユーザー間の一意性に関して、異なる Issuer をまたいで、sub のような保証を行うことはできない • Issuer はローカルの制限やポリシーを適用することが許されている ◦ Issuer は異なる時点で異なる End-Users 間で email Claim 値を再利用するかもしれない (MAY) ◦ 特定の End-User の email Claim は時間の経過とともに変わりうる (MAY) ◦ ゆえに, email, phone_number, preferred_username のような他の Claims は End-User の一意な識別子 として使用してはいけない (MUST NOT) OpenID Connect が定める技術仕様 61 メールアドレスをユーザー識別子として使用するリスク 参考：「Final: OpenID Connect Core 1.0 incorporating errata set 1」 　https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#IDToken 　https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#ClaimStability
62. 適切なもの • ランダムに生成された識別子 (例: UUID) • 一意かつ、変化せず、再割り当てされない値であるもの 不適切なもの • メールアドレス • ID 基盤上の内部 id (例: 自動採番された数値) RP に連携するユーザー識別子として何が適切か 62 メールアドレスをユーザー識別子として使用するリスク
63. 進んだ補足 : PPID について 1/2 63 メールアドレスをユーザー識別子として使用するリスク 複数の RP に同じ識別子を連携すると、RP 間で紐付け (名寄せ) が行えてしまう
64. 進んだ補足 : PPID について 2/2 64 メールアドレスをユーザー識別子として使用するリスク RP ごとに異なる識別子を割り当てて、紐付けができないようにする
65. メールアドレスをユーザー識別子として扱う場合のリスク • メールアドレスの所有者が別の人になっている可能性がある • メールアドレスの所有者が確認されていない可能性がある • OP 側でメールアドレスが変更されたことを RP 側で検知できない • RP 側にメールアドレスを隠すことができない OpenID Connect の実装者の観点で気をつけること • OP は ID Token の sub (= ユーザー識別子) にメールアドレスを用いない • RP は ID Token, UserInfo で得たメールアドレスをユーザー識別子として扱わない • ユーザー識別子には一意かつ、変化せず、再割り当てされない値を用いる まとめ 65 メールアドレスをユーザー識別子として使用するリスク
66. アクセストークンの検証と取り扱い 67
67. • OAuth 2.0 でのアクセストークン発行 & 利用の流れの振り返り • アクセストークンの種類 • アクセストークンの種類に応じた、情報を得る手段 • 権限判定に必要な情報 目次 68 アクセストークンの検証と取り扱い
68. どうやって特定のアクセスだけを許可するか？ 1/5 69 アクセストークンの検証と取り扱い クライアントは認可サーバーにアクセスしたいリソースを表明する
69. どうやって特定のアクセスだけを許可するか？ 2/5 70 アクセストークンの検証と取り扱い ユーザーを認証して「誰が」リソースへのアクセスを許可するのか特定する
70. どうやって特定のアクセスだけを許可するか？ 3/5 71 アクセストークンの検証と取り扱い ユーザーにアクセスへの同意を求める
71. どうやって特定のアクセスだけを許可するか？ 4/5 72 アクセストークンの検証と取り扱い ユーザーがアクセスに同意したことを表すトークンをクライアントに渡す
72. どうやって特定のアクセスだけを許可するか？ 5/5 73 アクセストークンの検証と取り扱い クライアントが正規のアクセストークンを持っていることを検証
73. どうやって特定のアクセスだけを許可するか？ 5/5 74 アクセストークンの検証と取り扱い クライアントが正規のアクセストークンを持っていることを検証 リソースサーバーがアクセストークンによる権限範囲を知る方法は？
74. Handle (または Artifact) • トークンは認可サーバー上のデータに対する参照のキーとなる役割 • トークンそのものには情報を含まず、データの参照と合わせて利用する Assertion • トークンの内部に情報を含める • 有効期間と発行対象の情報を持つことが多い • 改竄防止および発行者認証のために電子署名が付けられることが多い トークンの形式の種類 75 アクセストークンの検証と取り扱い ここでの「トークン」は アクセストークンに限らず リフレッシュトークンや認可コードも含む
75. Handle: アクセストークンが単なるキーである場合 • リソースサーバーが認可サーバーのデータに直接アクセスできない場合 ◦ 認可サーバーに問い合わせる ◦ アクセストークンそのものは、認可情報を取得するための識別子でしかない ◦ アクセストークンを認可サーバーに送り、レスポンスとして認可情報を受け取る ◦ パフォーマンスやスケーラビリティの点で不利 ◦ 参考仕様: RFC 7662 - OAuth 2.0 Token Introspection • リソースサーバーが認可サーバーのデータに直接アクセスできる場合 ◦ アクセストークンを用いて DB を直接参照し、情報を取得する ◦ リソースサーバーと認可サーバーが同一である場合、パフォーマンス等の懸念が小さい アクセストークンの形式に応じた情報取得の手段 1/6 76 アクセストークンの検証と取り扱い
76. アクセストークンの形式に応じた情報取得の手段 2/6 77 アクセストークンの検証と取り扱い Handle でリソースサーバーが認可サーバーのデータに直接アクセスできない場合
77. アクセストークンの形式に応じた情報取得の手段 3/6 78 アクセストークンの検証と取り扱い Handle でリソースサーバーが認可サーバーのデータに直接アクセスできる場合
78. Assertion: アクセストークン自体が情報を持っている場合 • アクセストークンの中に情報を入れ込む ◦ アクセストークンを JSON にするなどして、データを内部に含める ◦ 改竄を防ぐために署名が必要 ◦ Handle の場合と比較して失効させるのが大変 ◦ データを含められる (JSON) + 署名が入れられる (JWS) ため、JWT がよく利用される ◦ JWT 以外にも暗号化・署名付きの独自フォーマットのケースもある ◦ 参考仕様: RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens アクセストークンの形式に応じた情報取得の手段 4/6 79 アクセストークンの検証と取り扱い
79. アクセストークンの形式に応じた情報取得の手段 5/6 80 アクセストークンの検証と取り扱い Assertion の場合は認可サーバーとのやりとりなく権限判定が可能
80. Handle: アクセストークンが単なるキーである場合 • 認可サーバーとリソースサーバーが通信できない場合は使えない • ケースによって、パフォーマンスやスケーラビリティの観点で不利 Assertion: アクセストークン自体が情報を持っている場合 • Handle の場合と比較して失効させるのが大変 • クライアントに読まれる可能性があるので、含める情報に注意 アクセストークンの形式に応じた情報取得の手段 6/6 81 アクセストークンの検証と取り扱い
81. クライアント • 認可サーバーからアクセストークンを受け取り、リソースサーバーに送る • クライアントはアクセストークンの解釈・検証を行わない リソースサーバー • アクセストークンに紐づく様々な情報から、受け入れ可否を判断 • 受け入れ可能な場合、それによりアクセス可能なリソースを判断 アクセストークンの取り扱い 82 アクセストークンの検証と取り扱い
82. scope • 意味：クライアントがどのリソースへのアクセスを許可されたか? • 何を検証するか：要求されたリソースへの操作と scope の紐付き • 検証しない場合：アクセスを許可していないリソースへの操作が行われる subject • 意味：どのリソースオーナーの同意に基づいて発行されたか • 何を検証するか：要求されたリソースと subject の紐付き • 検証しない場合：アクセスを許可していないリソースへの操作が行われる アクセストークンを受け入れる際に検証すべき情報 1/3 83 アクセストークンの検証と取り扱い
83. issuer • 意味：どの認可サーバーにより発行されたか • 何を検証するか：アクセストークンを要求した先と一致するか • 検証しない場合：偽造されたアクセストークンを受け入れてしまう audience • 意味：どのリソースサーバーが受け取ることを想定して発行されたか • 何を検証するか：リソースサーバー自身の識別子を含むか • 検証しない場合：異なる用途のトークンを受け入れてしまう アクセストークンを受け入れる際に検証すべき情報 2/3 84 アクセストークンの検証と取り扱い
84. 有効期限 • 意味：アクセストークンの有効期限がいつまでか • 何を検証するか：有効期限が切れていないか • 検証しない場合：アクセス許可を取り消した後でも操作が行われる この他にも発行日時 (iat) や有効になる日時 (nbf) などあるが、省略 Assertion の場合には、改竄されたトークンを受け入れないよう署名検証も必要 アクセストークンを受け入れる際に検証すべき情報 3/3 85 アクセストークンの検証と取り扱い
85. アクセストークンの形式 • Handle (または Artifact)：権限情報を参照するキーの役割のみを果たす • Assertion：トークンそのものに権限情報を内包する アクセストークンの検証 • 権限判定には scope, subject, issuer など多様な情報が必要 • これらそれぞれを適切に検証しないと、様々なリスクが発生する まとめ 86 アクセストークンの検証と取り扱い
86. © OpenID Foundation Japan 登壇者紹介（認可・ ID連携担当） 87 米田良平 事業会社においてコンシューマ向けの認証認可基盤の構築を 担当しております。 私自身、ID/OIDCについて初心者ですので、みなさまと一緒に 学んで、OIDCに限らずIDの利用環境をよりよくすることに貢献 していきたいと思います。
87. OIDCにおけるCSRF 88
88. CSRFとは 89 CSRFとはCross-Site Request Forgeries（クロスサイト・リクエスト・フォージェリ）の略 で、Webアプリケーションの脆弱性の一つである。 この脆弱性を悪用した攻撃のことをCSRF攻撃という。 ログインした利用者からのリクエストについて、その利用者が意図したリクエストである かどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のある リクエストを受け入れてしまう場合がある。このようなウェブサイトにログインした利用者 は、悪意のある人が用意した罠により、利用者が予期しない処理を実行させられてしま う可能性がある。※ 1.1. CSRFとは ※引用：独立行政法人情報処理推進機構..”安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）”.https://www.ipa.go.jp/security/vuln/websecurity/csrf.html, (参照2024-11-11)
89. OpenID Connect（OIDC）とCSRF 90 OIDCはOAuth2.0をベースとした仕組みである。 OAuth2.0にはCSRFの脆弱性が存在するためCSRF攻撃を受けるリスクがある。 そのため、OIDCにおいても同様の脆弱性が存在することになる。 具体的には、リダイレクトURIに対してCSRF攻撃が行われる可能性がある。この攻撃で は、攻撃者のアカウントに紐づくリソースの操作権限が付与されたアクセストークンを利 用者に利用させ、攻撃者のリソースに利用者の情報を書き込ませることができ、攻撃者 は自身のアカウントにアクセスして利用者の情報を盗みとることが可能となる。 OAuth2.0の認可コードフローでCSRFの攻撃のメカニズムと対策を解説する。 1.1. CSRFとは
90. 利用者には知らず知らずのうちに攻撃者の権限が付与され、以下のような被害が発生 する。 被害例） 1. driveサービスの場合、攻撃者のdriveへ利用者のファイルがアップロードされてしま う。 2. 金融系サービスの場合、攻撃者のアカウントに利用者のクレカや口座情報が登録 されてしまう。 3. ECサイトの場合、攻撃者のアカウントに利用者などの送付先住所等が紐づけられ てしまう。 4. ポイント移行サイトの場合、攻撃者のアカウントに利用者のポイントが移行されてし まう。 この脆弱性による具体的な被害とは 91 1.1. CSRFとは
91. 以下のように認可コードフローは実行される。 認可コードフローの復習 92 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ①リソースオーナーが処理開始 ②クライアントが認可リクエストを実施 ③認可サーバーはログイン画面を返却 ④利用者がクレデンシャル入力 ⑤認可サーバーは同意画面を返却 ⑥利用者が同意する ⑦認可サーバーが認可コードを返却 ⑧クライアントが⑦で受け取った認可コードでア クセストークンリクエスト ⑨認可サーバーがアクセストークン /IDトークン返 却 ⑩アクセストークンでユーザー情報取得要求 ⑪リソースサーバーは clames返却 ⑫Clientでログイン処理を実施しログイン完了 ⑨ ⑩ ⑪ ⑫
92. 認可コードは認証/認可を行ったリソースオーナーのものとして発行される。 仮に、認可コードを盗み取って他人が利用すると、盗み取られた人のリソースにアクセス できてしまうことになる。CSRFはこの点も突く脆弱性と言える。 認可コードとリソースオーナー 93 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ 認証認可を行ったリソースオーナーものとして、 認可コードが発行される。
93. 攻撃者は事前準備として、攻撃者自身のアカウントで認証認可を済ませ認可コードを取 得する。 攻撃者による事前準備 94 1.2. CSRFの解説 リソースオーナー （被害者） ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ①攻撃者 が処理開始 ②クライアントが認可要求を実施 ③認証認可サーバーはログイン画面を返却 ④攻撃者 がクレデンシャル入力 ⑤認可サーバーは同意画面を返却 ⑥攻撃者 が同意する ⑦認可サーバーが 攻撃者へ 認可コードを返却 ⑦攻撃者に紐づく認可コードを取得する リソースオーナー （攻撃者）
94. 攻撃者は利用者に悪意あるURIを送付しクリックさせ、利用者に対して攻撃者のアカウ ント操作権限を付与させる。 利用者をだます 95 1.2. CSRFの解説 リソースオーナー （被害者） クライアント 認可サーバー リソースサーバー ① リソースオーナー （攻撃者） ユーザーエージェント ⑦́攻撃者が利用者へ何らかの手段で利用者に対して⑦で 受け取った認可コードを含むリダイレクトURIを送る ⑦́́利用者がURIをクリックする ⑧クライアントが⑦で受け取った認可コードでアクセストーク ンリクエスト ⑨認可サーバーがアクセストークン/IDトークン返却 ⑩アクセストークンでユーザー情報取得要求 ⑪リソースサーバーはclames返却 ⑫Clientでログイン処理を実施し攻撃者のアカウントとしてロ グイン完了 ⑦́悪意あるURIを送付 ⑦́́悪意あるURIをクリック ⑧ 攻撃者が取得した認可コードでアク セストークンリクエストが実行される ⑨攻撃者に紐づく アクセストークンが 返却される ⑩ ⑪攻撃者のリソース情 報が返却される
95. 利用者には知らず知らずのうちに攻撃者の権限が付与され、以下のような被害が発生 する。 被害例） 1. driveサービスの場合、攻撃者のdriveへ利用者のファイルがアップロードされてしま う。 2. 金融系サービスの場合、攻撃者のアカウントに利用者のクレカや口座情報が登録 されてしまう。 3. ECサイトの場合、攻撃者のアカウントに利用者などの送付先住所等が紐づけられ てしまう。 4. ポイント移行サイトの場合、攻撃者のアカウントに利用者のポイントが移行されてし まう。 この脆弱性による具体的な被害とは（再掲） 96 1.1. CSRFとは
96. フロー上の②から⑧のセッションが同一であることの保証がないから。 なぜCSRFが発生するのか？ 97 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ①利用者が処理開始 ②Back-End Serverが認可リクエストを実施 ③認証認可サーバーはログイン画面を返却 ④利用者がクレデンシャル入力 ⑤認証認可サーバーは同意画面を返却 ⑥利用者が同意する ⑦認証認可サーバーが認可コードを返却 ⑧Back-End Serverが⑦で受け取った認可コー ドでアクセストークンリクエスト ⑨認証認可サーバーがアクセストークン /IDトー クン返却 ⑩アクセストークンでユーザー情報取得要求 ⑪Userinfoはclames返却 ⑫Clientでログイン処理を実施しログイン完了 ⑨ ⑩ ⑪ ⑫ このセッションが同一であることの保 証がない
97. OAuth2.0（RFC6749）において、クライアントは自身のリダイレクトURIに対してCSRF 保護対策をすることを義務づけている。OAuth2.0ではその対策としてstateを利用を推 奨しており、stateを利用することがCSRF攻撃への対策となる。 stateは推測不能な値である必要がある。具体的な推測可能性は1/2^(-128)以下でなけ ればならず、1/2^(-160)以下であればなおよいとされている。 stateによる対策 98 1.3. CSRF対策
98. クライアントにて認可リクエスト時にstateを付与し、認可コード受取時のstateと比較を行 うことで、セッションの同一性が担保され、CSRF対策として有効。 stateの検証はクライアント、即ち、RPが行う点も対策のポイント。 stateによる対策 99 1.3. CSRF対策 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ② state=αβγ　 ⑦ state=αβγ stateを認可serverへ送 信する ②で受け取った stateを 認可コードを返却する stateを生成しセッション に紐づけ クライアントでセッションに紐づ いたstateと受け取ったstateの 検証を実施 stateが一致することで、セッションの 同一性がほしょうされる。
99. • OIDCにはCSRF攻撃を受けるリスクがある。 • CSRF攻撃への対策にはstateの利用が有効。 • 認可サーバー（OIDCではIdP）、クライアント（OIDCではRP）が協力して対策を行う 必要がある。 • stateについては、クライアント（RP）で検証することで、有効に機能することを踏ま えて、クライアントは実装する必要がある。 CSRFまとめ 100 1.4. まとめ
100. stateと同等の役割を果たすパラメータとしてPKCEとnanceがある。それぞれについて概説しす る。 【PKCE】 OAuth2.0には認可コードを横取りされるリスクがあり、その対策として RFC7636で定義された PKCE（ピクシーと読む）を利用する事が望ましい。OIDCにおいても同様である。 【nonce】 OIDCではリプレイアタック対策としてnonce（ナンスと読む）が定義されている。 いずれのパラメータも、目的は違うものの同一セッションを保証するためのパラメーターとして機 能するため、次ページ以降でシーケンスを用いて解説する。 PKCEとnonce 101 1.5.Appendix
101. PKCEを利用することで、認可サーバー側でどの認可リクエストに対して発行した認可 コードか判別できるため、横取りされた認可コードを利用することはできない。（詳細は 「PKCE概要」を参照） PKCEの概要 102 1.5.Appendix リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ② code_challenge=αβγ　 ⑧code_verifier =abc クライアントは改めて PKCEを送信する code_challengeを を認可サーバーへ送信する code_verifierを code_challengeに変換し ②の値と比較検証 認可サーバーは PKCEと認可 コードを対で保持する
102. nonce（詳細はspecを参照）を利用することで、クライアント側でIDトークンの再利用を検 知することができ、リプレイアタックが成立しない。 nonceの概要 103 1.3. CSRF対策 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー 受け取ったnonceと②の nonceを比較検証する nonceを認可サーバー へ送信する ②のnonceをIDトークンに 含めて返却する ⑨nonce=αβγ ② nonce=αβγ　
103. IDPはいずれのパラメータも利用できるようサービス提供することになる。 一方でRPもパラメータの意味を理解したうえで必要な処理を実装し、利用者を不正から 保護しなければならない。 stateとPKCEとnonceのまとめ 104 1.3. CSRF対策 パラメータ 防げる脆弱性 実装の主体者 ポイント state CSRF RP RP側で認可リクエストと認可コード受領時 点のセッション同一性保証ができる。 PKCE 認可コード横取り IDP IDP側で認可リクエストとアクセストークンリ クエストのセッション同一性保証ができる。 nonce リプレイアタック RP RP側で認可リクエストと IDトークン受領時点 のセッション同一性保証ができる。
104. © OpenID Foundation Japan 登壇者紹介 105 糸井佑磨（株式会社オプティム） IT×農業のシステム開発をしております。 私自身ID初学者ですが分かりやすく噛み砕いた説明になるよ う考えました。 認証担当
105. 7つの認証タイプ 106
106. 目次 107 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
107. 目次 108 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
108. 1. 背景・概要 109 • 2要素認証でもフィッシングにより当人認証 (Authentication)が破られる事例があり、昨今は フィッシング情報の届出件数も増えている。 • 当人認証の保証レベル(Authentication Assurance Level、以下、AAL)や認証器タイプ (Authenticator Type)について知ることで、フィッシング耐性があり、普及期にあるパスキーへ の理解を深める足掛かりとする。 7つの認証器タイプ - 1. 背景・概要 引用：「フィッシング対策協議会 / フィッシングレポート 2023」https://www.antiphishing.jp/report/phishing_report_2023.pdf
109. 目次 110 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
110. 2. 認証の定義 111 Authentication (当人認証)には強度という概念が存在する。 例えば、読書記録アプリに比べて金融系アプリでは、当人認証が侵害された際の 金銭的損失の影響度が大きく、より高い強度が求められる。 AuthenticationにはAuthenticator Type (認証器タイプ)という分類があり、それぞれ で強度 ≒ Authentication Assurance Level (AAL: 当人認証保証レベル)が定義さ れている。 Authenticator Typeの分類にあたって、Authenticationの定義を本セクションで、 AALの定義を次セクションで理解する。 7つの認証器タイプ - 2. 認証の定義
111. 3. 認証の定義 112 Digital Authenticationとは、 デジタルアイデンティティの確らしさを確立するプロセス。 7つの認証器タイプ - 2. 認証の定義 # Digital Authentication 情報システムに対して、電子的に表現されたユーザーの Identity の確からしさを確立するプロセス。 SP 800-63 の前エディションまでは Electronic Authentication と呼ばれていたもの。 The process of establishing confidence in user identities that are digitally presented to a system. In previous editions of SP 800-63, this was referred to as electronic authentication. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
112. 2. 認証の定義 113 Authenticationとは、 Authenticatorの所有及び管理を証明するプロセス。 7つの認証器タイプ - 3. 認証の定義 # Authentication Claimantが、Subscriberアカウントにバインドされた 1つまたは複数の認証器の所有及び管理を証明し、それら認 証子がそのアカウントと共に Subscriberに関連付けられていることを証明するプロセス。 The process by which a claimant proves possession and control of one or more authenticators bound to a subscriber account to demonstrate that they are the subscriber associated with that account. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
113. 2. 認証の定義 114 Authenticatorとは、 ClaimantのIdentityをAuthenticationする際、所有および管理を証明さ れるもの。 7つの認証器タイプ - 2. 認証の定義 # Authenticator Subscriber が所有および管理(例としては暗号モジュールやパスワード等 )するもので。Claimant の Identity を Authenticate するために用いられる。 Something that the subscriber possesses and controls (e.g., a cryptographic module or password) and that is used to authenticate a claimant’s identity. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
114. 2. 認証の定義 115 Authenticator Typeとは、 共通の特徴を持つAuthenticatorの分類。 7つの認証器タイプ - 2. 認証の定義 # Authenticator Type Authenticatorが提供するAuthentication FactorやAuthenticatorの動作メカニズムに対して、共通の特徴を持つ Authenticatorのカテゴリー。 A category of authenticators with common characteristics, such as the types of authentication factors they provide and the mechanisms by which they operate. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
115. 2. 認証の定義 116 Authentication Factorとは、 something you know, something you have, something you areを指 す。 7つの認証器タイプ - 2. 認証の定義 # Authenticator Type Authentication Factor にはsomething you know, something you have, something you are の3つの種類があ る。すべてのAuthenticatorは1つ以上のAuthentication Factorを持つ。 The three types of authentication factors are something you know, something you have, and something you are. Every authenticator has one or more authentication factors. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
116. 目次 117 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
117. 3. AALの定義 118 ClaimantのIdentityをAuthenticationする際の証明には、強度という概念がある。 強度は、保証レベル(Assurance Level)で記述される。 当人認証に対する保証レベルは、AAL(Authentication Assurance Level)で定義さ れる。 NIST SP 800-63B では The Digital Identity Risk Management Process(DIRM Process)に沿って、AALを元にAuthenticator Typeを整理しているため、DIRM Process、AALの定義についても参照する。 7つの認証器タイプ - 3. AALの定義 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
118. 3. AALの定義 119 DIRM Processとは、 オンラインサービスを受けたい人が受けられるようになっていることを 大前提として、 損害と影響を評価し、 保証レベルを選択・カスタマイズして、 継続的に評価・改善を行うこと。 AALは、 「Step3」で選択され、「Step4」でカスタマイズされる。 7つの認証器タイプ - 3. AALの定義 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Step1: オンラインサービスを定義する Step2: ユーザー層毎に初期影響評価を 実施する Step3: ユーザー層毎に初期保証レベルと ベースラインコントロールを選択する Step4:ユーザー層毎に保証レベルを カスタマイズして文書化する オンラインサービスのための ID管理システムを、導入 /調整する Step5:継続的に評価し改善する
119. 3. AALの定義 120 AAL(Authentication Assurance Level)とは、 Authenticationプロセス自体、およびAuthenticatorと個人の紐付けの 堅牢性。 7つの認証器タイプ - 3. AALの定義 # AAL Authentication プロセス自体、および Authenticator と特定個人の識別子の紐付けの頑強性。 AAL は 潜在的な Authentication 失敗から生じるリスクを軽減するために選択される。 The robustness of the authentication process itself, and the binding between an authenticator and a specific individual’s identifier. The AAL is selected to mitigate risks that result from potential authentication failures. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
120. 3. AALの定義 121 AAL1とは、 基本レベルの信頼性を提供する。1要素認証のみが要求される。 7つの認証器タイプ - 3. AALの定義 # AAL1 AAL1 は、Claimantが、認証されるSubscriber Accountにバインドされている認証器を管理しているという基本レベルの信頼性を提供する。 AAL1 では、利用可能な幅広い認証技術を使用した 1 要素認証のみが要求される。ただし、 AAL1 と評価されるオンライン・サービスは、多要 素認証オプションを提供することが推奨される。認証を成功させるには、 ClaimantがAuthenticatorを所有し管理していることを証明する必要が ある。 AAL1 provides a basic level of confidence that the claimant controls an authenticator bound to the subscriber account being authenticated. AAL1 requires only single-factor authentication using a wide range of available authentication technologies. However, it is recommended that online services assessed at AAL1 offer multi-factor authentication options. Successful authentication requires that the claimant prove possession and control of the authenticator. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
121. 3. AALの定義 122 AAL2とは、 高い信頼性を提供する。2つの異なるAuthentication Factorを所有・管理して いる証明が必要とされる。フィッシング耐性のある認証オプションが提供されな ければならない。 7つの認証器タイプ - 3. AALの定義 # AAL2 AAL2 は、Claimantが、認証されるSubscriber Accountにバインドされている 1 つ以上の Authenticatorを管理しているという高い信頼性を提供 する。2 つの異なるAuthentication Factorを所有し管理していることの証明が必要である。 AAL2 と評価されるオンライン・サービスには、フィッ シング耐性のある認証オプションが提供されなければならない . AAL2 provides high confidence that the claimant controls one or more authenticators bound to the subscriber account being authenticated. Proof of possession and control of two distinct authentication factors is required. A phishing-resistant authentication option must be offered for online services assessed at AAL2. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
122. 3. AALの定義 123 AAL3とは、 非常に高い信頼性を提供する。2つの異なるAuthentication Factorを所有・管理している証明が必要とさ れる。エクスポート不可能な秘密鍵を持つハードウェアベースのAuthenticatorと、フィッシング耐性のある Authenticatorが必要である。 7つの認証器タイプ - 3. AALの定義 # AAL3 AAL3 は、Claimantが、認証されるSubscriber Accountにバインドされている一つ以上の Authenticatorを管理しているという非常に高い信頼性 を提供する。AAL3 での認証は、公開鍵暗号プロトコルの使用による鍵の所有証明に基づいている。 AAL3 認証には、エクスポート不可能な秘 密鍵を持つハードウェアベースの Authenticatorと、フィッシング耐性のある Authenticatorが必要である。同じデバイスが両方の要件を満たすこ ともある。AAL3 で認証するために、 Claimantは、2 つの異なるAuthentication Factorの所有と管理を証明する必要がある。 AAL3 provides very high confidence that the claimant controls one or more authenticators bound to the subscriber account being authenticated. Authentication at AAL3 is based on the proof of possession of a key through the use of a public-key cryptographic protocol. AAL3 authentication requires a hardware-based authenticator with a non-exportable private key and a phishing-resistant authenticator; the same device may fulfill both requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
123. 3. AALの定義 124 以上の定義から、オンラインサービスに必要な保証レベルを制御目的に応じて選択 ・カスタマイズすることが重要である 7つの認証器タイプ - 3. AALの定義 #Table 2. AAL Summary. 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e AAL 制御目的 AAL1 攻撃に対する最低限の保護を提供する。パスワードに焦点を当てた攻撃を阻止する AAL2 多要素認証をサポートする。フィッシング耐性のオプションを提供する AAL3 フィッシング耐性とVerifier侵害への保護を提供する
124. 目次 125 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
125. 4. 7つの認証器 126 NIST SP 800-63B では DIRM Process に沿って、AALを元にAuthenticator Type を整理している。 しかし、高い信頼性を提供するAAL2に分類されるAuthenticator Typeであっても、 フィッシングによりAuthenticationが破られる事例がある。 そのため、以降ではAALも参照しつつ、大枠ではフィッシング耐性有無によって Authenticator Typeを概説する。 Authenticator Typeによっては各AALを満たすための追加要件もあるが、ここでは 各Authenticator Typeの典型的な使用例に絞って概説する。 7つの認証器タイプ - 4. ７つの認証器
126. 4. 7つの認証器 127 7つの認証器の概説と事例は以下のようにまとめられる。 以降で個別にシーケンス・AAL・メリット・デメリットを整理する。 7つの認証器タイプ - 4. ７つの認証器 Authenticator Type 概説 事例 パスワード Subscriberが選択した、Authentication Factorとして使用されるシークレットを使用した Authentication パスワード、PIN、APIキーなど ルックアップシークレット Verifierが発行した、所有を証明するために 1度だけ使用されるシークレットを使用した Authentication ユーザーに関する秘密の質問やセキュリティカードなど アウトオブバンドデバイス Verifierが生成し、Subscriberのデバイスに独立して送信される、短期間だけ有効なシークレットを使用した Authentication SMS/電話音声/メールによるOTP、デバイスへのプッシュ通知、 QRコード スキャンなど 単一要素OTP OTPの生成をサポートするデイバイスやソフトウェアを使用した Authentication トークンアプリやカード型トークンなど 多要素OTP 追加の認証要素によりアクティベートされた後に、単一要素 OTPを行うAuthentication PINコードで有効になる YubiKeyなど 単一要素暗号 認証プロトコルを介して暗号鍵の所有と管理を証明することによって行われる Authentication Appleのキーチェーンやパスワードマネージャ、 USBセキュリティトークンや スイカのようなスマートカード 多要素暗号 ユーザーが2つ以上の異なる認証要素を提供することでアクセスを許可する Authentication Google AuthenticatorやMicrosoft Authenticator、YubiKeyやGoogle Titan Security Keyなど 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
127. 目次 128 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
128. 4-1. フィッシング耐性が ない認証器の説明 129 パスワード 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Subjectが発行
129. 4-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ 実装が簡単でユーザーも理解しやすい ◦ 特別なハードウェアが不要 • デメリット ◦ 弱いパスワードや再利用されたパスワードは破られやすい ◦ フィッシング攻撃やブルートフォース攻撃に弱い 130 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
130. 4-1. フィッシング耐性が ない認証器の説明 131 ルックアップシークレット 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e CSPが発行
131. 4-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ ユーザーが覚える必要がない情報を利用できる ◦ 物理的なアイテムや生体情報を利用することで、セキュリティを強化できる • デメリット ◦ 秘密の質問は予測可能な回答が多く、セキュリティが低い場合がある ◦ 生体認証デバイスや特殊なカードが必要な場合、コストがかかる 132 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
132. 4-1. フィッシング耐性が ない認証器の説明 133 アウトオブバンドデバイス(PrimaryDeviceにシークレットを転送する場合) 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Verifierが発行し、 SecondaryDeviceに表示させ、 PrimaryDeviceで入力
133. 4-1. フィッシング耐性が ない認証器の説明 134 アウトオブバンドデバイス(Out-of-band Deviceにシークレットを転送する場合) 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Verifierが発行し、 PrimaryDeviceに表示させ、 SecondaryDeviceで入力
134. 4-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ 主要な通信チャネルとは別の手段を使用するため、セキュリティが強化される ◦ ユーザー体験が向上し、利便性が高い • デメリット ◦ SMSやメールは中間者攻撃に弱いことがある ◦ 通信障害があると認証ができない場合がある 135 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
135. 4-1. フィッシング耐性が ない認証器の説明 136 単一要素OTP 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e OTP Device or Softwareが発行し、 PrimaryChannelで入力
136. 4-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ パスワードよりも安全な一度きりのパスワードを提供できる ◦ ユーザーが持ち運び可能である • デメリット ◦ デバイスを紛失した場合、アクセスができなくなる ◦ デバイスが必要なため、コストがかかる 137 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
137. 4-1. フィッシング耐性が ない認証器の説明 138 多要素OTP 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e パスワードで1度目のverifyを行い、 OTP Device or Softwareが発行し、 PrimaryChannelで入力して2度目の verifyを行う
138. 4-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1, AAL2 • メリット ◦ 単一要素よりもセキュリティが強化される ◦ パスワードとデバイスの組み合わせが不正アクセスを防ぐ • デメリット ◦ デバイスを紛失するとアクセスが困難になる ◦ 初期設定や管理が複雑になることがある 139 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
139. 4-1. フィッシング耐性が ない認証器の説明 140 単一要素暗号認証 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e パスワードは秘密鍵の暗号化に 使用され、認証要素ではない。 公開鍵暗号方式であり、 something you haveの単要素認証となる。
140. 4-1. フィッシング耐性が ない認証器の説明 • Channel Binding、Verifier Name Bindingを満たす場合のみフィッシング耐性あり • AAL ◦ AAL1, AAL2 • メリット ◦ ユーザーは 1つの情報を覚えておけばよく、使用が簡単 ◦ 様々なシステムで広く使用されており、ユーザーにも馴染み深い • デメリット ◦ 単一の認証要素が侵害されると不正アクセスが可能になるためセキュリティが比較的低い ◦ 暗号技術の正確な実装と管理が必要で、実装が複雑 141 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
141. 目次 142 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
142. 4-2. フィッシング耐性が ある認証器の説明 143 多要素暗号認証 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e パスワードも認証要素として使用する。 秘密鍵の暗号化には別の仕組みを使用する。 公開鍵暗号方式と組み合わせるため、多要素認証となる
143. 4-2. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1, AAL2, AAL3 • メリット ◦ 複数の認証要素を組み合わせることで不正アクセスのリスクを大幅に低減できる • デメリット ◦ 初期設定が複雑で一部のユーザーにとっては障壁になることがある 144 7つの認証器タイプ - 4. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
144. 目次 145 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
145. 5. toB, toCでの事例 146 ここまで、フィッシング耐性有無やAALを元にAuthenticator Typeを整理してきた。 上記を踏まえ、toB, toCでの各ガイドラインを参照し推奨される認証方式の事例紹介と 整理を行う。 7つの認証器タイプ - 5. toB, toCでの事例 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
146. 目次 147 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
147. 5-1. toBでの事例 148 大分類 ガイドライン 交通・物流分野 ・航空分野における情報セキュリティ確保に係る安全ガイドライン ・空港分野における情報セキュリティ確保に係る安全ガイドライン ・鉄道分野における情報セキュリティ確保に係る安全ガイドライン ・物流分野（貨物自動車運送）における情報セキュリティ確保に係る安全ガイドライン ・物流分野（倉庫）における情報セキュリティ確保に係る安全ガイドライン ・物流分野（船舶運航）における情報セキュリティ確保に係る安全ガイドライン ・港湾分野における情報セキュリティ確保に係る安全ガイドライン 製造分野 ・工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン ・ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド ・制御システムのセキュリティリスク分析ガイド ・建設現場ネットワークの構築と運用ガイドライン 医療分野 ・医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン ・医療情報システムの安全管理に関するガイドライン 商取引・決済分野 ・PCI-DSS ・ECサイト構築・運用セキュリティガイドライン 働き方関連 ・テレワークセキュリティガイドライン 7つの認証器タイプ - 5. toB, toCでの事例 toBでの事例として参照したガイドラインを以下のように分類した
148. 5-1. toBでの事例 - (まとめ) 149 7つの認証器タイプ - 5. toB, toCでの事例 それぞれの分類で、多要素認証を行う際の認証器タイプの組み合わせ例、事例は大まかに以下のように 整理できる 大分類 認証器タイプ組み合わせ例 事例 交通・物流分野 ・多要素OTP (パスワード + 単一要素OTP) ・多要素暗号 (パスワード + 単一要素暗号) ・PINコードを要求するセキュリティトークン ・Google Authenticator ・YubiKey 製造分野 ・多要素OTP (パスワード + 単一要素OTP) ・多要素暗号(パスワード + 単一要素暗号) ・パスワード + 手のひら静脈認証 ・Google Authenticator ・YubiKey 医療分野 ・パスワード + ルックアップシークレット ・PIN + 指紋認証 商取引・決済分野 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・パスワード + 秘密の質問 ・PIN + SMSによるOTP 働き方関連 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・PIN + 秘密の質問 ・パスワード + メールへのマジックリンク送信
149. 5-1. toBでの事例 - (まとめ) 150 7つの認証器タイプ - 5. toB, toCでの事例 • 内閣サイバーセキュリティセンターによって重要インフラ分野として特定されている分野において はほとんどの場合、多要素認証が必要とされている。 • 重要インフラ以外の分野においても、乗っ取りや成りすましの対策として多要素認証が例示され ている。 • NIST-SP-800-63-4-2PD においては多要素認証に分類される認証強度の中でもさらにフィッシン グ耐性の有無について言及していること、参照したガイドライン群の多くは NISTの文書を参考に 作成されていることから、国内のガイドライン群でもフィッシング耐性のある多要素認証に対する 記述が追加されていくと予想される。すでに、重要インフラ分野においてはフィッシング耐性のな い多要素認証が非推奨とされている場合もある。現在は AAL2相当の記述が多いが、 AAL3相当 の記述が追加されていくと予想される。
150. 目次 151 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
151. 5-2. toCでの事例 152 toCでの事例として参照したガイドライン・サービスを以下のように分類した 大分類 ガイドライン・サービス 高額決済サービス ・ドコモオンラインショップ ・メルコイン 商取引・決済分野 ・ECサイト構築・運用セキュリティガイドライン ・利用者向けフィッシング詐欺対策ガイドライン ・クレジットカード・セキュリティガイドライン ・メルカリ 医療分野 ・医療情報システムの安全管理に関するガイドライン 7つの認証器タイプ - 5. toB, toCでの事例
152. 5-2. toCでの事例 - (まとめ) 153 7つの認証器タイプ - 5. toB, toCでの事例 それぞれの分類で、多要素認証を行う際の認証器タイプの組み合わせ例、事例は大まかに以下のように 整理できる 大分類 認証器タイプ組み合わせ例 事例 高額決済サービス ・多要素暗号 (パスワード + 単一要素暗号) ・YubiKey ・Google Titan Security Key ・PassKey 商取引・決済分野 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・多要素OTP (パスワード + 単一要素OTP) ・パスワード + 秘密の質問 ・パスワード + SMSによるOTP ・Google Authenticator 医療分野 ・パスワード + ルックアップシークレット ・PIN + 指紋認証
153. 5-2. toCでの事例 - (まとめ) 154 7つの認証器タイプ - 5. toB, toCでの事例 • 幅広いユーザー層へのサービス提供を鑑み、多要素認証を必須にするまでは至っていない が、積極的に推奨はされている。 • 一部ではユーザー層と金銭的損失を鑑み、フィッシング耐性のある多要素認証の導入を必 須としているサービスも出てきており、これは AAL3に相当する。 • 金銭的損失の影響度が大きいサービス、医療情報など機密性が求められるサービスについ てはAAL3に相当するフィッシング耐性のある多要素認証が積極的に導入されていくと予想 される。
154. 目次 155 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
155. 6-1. 参考文献 • NIST (National Institute of Standards and Technology) ◦ SP 800-63-4 (2nd Public Draft) ▪ https://csrc.nist.gov/pubs/sp/800/63/4/2pd ▪ 米国政府機関システムの技術要件をまとめる NISTが提供するデジタル認証に関する包 括的なガイドライン ▪ 本資料で参照しているのは Finalではないことに留意 156 7つの認証器タイプ - 6. Appendix 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
156. 6-1. 参考文献 157 • フィッシング対策協議会 ◦ フィッシングレポート 2023 ▪ https://www.antiphishing.jp/report/phishing_report_2023.pdf ▪ 2023年のフィッシング詐欺の動向、手口、被害状況を分析し、特に ECサイトや SMSを悪 用した攻撃の増加傾向と対策について、統計データとともに報告するレポート ◦ 利用者向けフィッシング詐欺対策ガイドライン (2024年度版) ▪ https://www.antiphishing.jp/report/consumer_antiphishing_guideline_2024.pdf ▪ 一般利用者向けに、フィッシング詐欺の最新の手口や見分け方を解説し、 SMS・メール・ 偽サイトへの具体的な対処方法と予防策を示したガイドライン 7つの認証器タイプ - 6. Appendix
157. 6-1. 参考文献 158 • PCI SCC (Payment Card Industry Security Standards Council) ◦ PCI DSS v4.0.1 ▪ https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf ▪ クレジットカードの会員データを安全に取り扱うために策定されたセキュリティ基準 • IPA (独立行政法人情報処理推進機構 ) ◦ ECサイト構築・運用セキュリティガイドライン (2023年3月16日) ▪ https://www.ipa.go.jp/security/guide/vuln/ps6vr7000000acvt-att/000109337.pdf ▪ EC事業者向けに、サイト構築・運用における情報セキュリティ対策の基準を示し、利用者保護とサー ビスの安全性確保のための具体的な実施事項を解説したガイドライン • 一般社団法人日本クレジット協会 ◦ クレジットカード・セキュリティガイドライン 5.0 版 (2024年3月14日) ▪ https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines_5.0_published.pdf ▪ クレジットカード取引におけるセキュリティ対策の指針を示し、加盟店や事業者が実施すべきカード 情報保護、不正利用防止策を具体的に解説したガイドライン 7つの認証器タイプ - 6. Appendix
158. 6-1. 参考文献 159 • 内閣サイバーセキュリティセンター ◦ 重要インフラ対策関連 ▪ https://www.nisc.go.jp/policy/group/infra/policy.html • 国土交通省 ◦ 航空分野における情報セキュリティ確保に係る安全ガイドライン第 6版 (2024年4月25日) ▪ https://www.mlit.go.jp/koku/content/20240425-koku-CyberSecurity.pdf ◦ 空港分野における情報セキュリティ確保に係る安全ガイドライン第 3版 (2024年4月25日) ▪ https://www.mlit.go.jp/koku/content/20240425-kuko-CyberSecurity.pdf ◦ 鉄道分野における情報セキュリティ確保に係る安全ガイドライン第 5版 (2024年4月18日) ▪ https://www.mlit.go.jp/tetudo/content/001738865.pdf ◦ 物流分野(貨物自動車運送 )における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ▪ https://www.mlit.go.jp/jidosha/content/001742060.pdf ◦ 物流分野(倉庫)における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ▪ https://www.mlit.go.jp/jidosha/content/001742057.pdf ◦ 物流分野(船舶運航)における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月26日) ▪ https://www.mlit.go.jp/maritime/content/001744764.pdf ◦ 港湾分野における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ▪ https://www.mlit.go.jp/kowan/content/001738824.pdf 7つの認証器タイプ - 6. Appendix
159. 6-1. 参考文献 160 • IPA (独立行政法人情報処理推進機構 ) ◦ ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド (2023年7月) ▪ https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2023/t6hhco000000ysp4-att/t6hhco00 0000z6en.pdf ▪ ビル設備の管理者向けに、空調・電気・監視カメラ等の制御システムにおけるサイバーセキュリティ対策の自己点 検項目と評価基準を解説したガイド ◦ 制御システムのセキュリティリスク分析ガイド第 2版 (2023年3月) ▪ https://www.ipa.go.jp/security/controlsystem/ug65p90000019bkg-att/begoj9000000hpm8.pdf ▪ 産業用制御システムにおけるセキュリティリスクの特定・分析・評価の手順を示し、対策の選定から実装までのプ ロセスを体系的に解説したガイド 7つの認証器タイプ - 6. Appendix
160. 6-1. 参考文献 161 • 経済産業省 ◦ 工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 (2022年11月16日) ▪ https://www.meti.go.jp/policy/netsecurity/wg1/factorysystems_guideline_ver1.0.pdf ▪ 製造業24業種の工場に向け、各業界・個社が自主的にセキュリティ対策を実施するための包括的な ガイドライン • 一般社団法人日本建設業連合会 ◦ 建設現場ネットワークの構築と運用ガイドライン (2024年2月) ▪ https://www.nikkenren.com/publication/fl.php?fi=1416&f=202404_nwglcs.pdf ▪ 建設現場における一時的なネットワーク環境の構築・運用に関して、セキュリティ対策や安全管理の 基準を示し、具体的な実装方法を解説したガイドライン 7つの認証器タイプ - 6. Appendix
161. 6-1. 参考文献 162 • 総務省 ◦ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 2.0 版(案) (2024年10月1日) ▪ https://www.soumu.go.jp/main_content/000970142.pdf ◦ テレワークセキュリティガイドライン第 5版 (2021年5月) ▪ https://www.soumu.go.jp/main_content/000752925.pdf • 厚生労働省 ◦ 医療情報システムの安全管理に関するガイドライン第 6.0版(システム運用編 ) (2023年5月) ▪ https://www.mhlw.go.jp/content/10808000/001112044.pdf 7つの認証器タイプ - 6. Appendix
162. 6-1. 参考文献 163 • 株式会社NTTドコモ ◦ 日本銀行決済機構局 「ISOパネル（第 7回）生体認証技術の金融サービスへの活用 ―新しい国際標準 ISO 19092 の概要と活用可能性 ―」パネルディスカッション～生体認証技術の活用と展望 (2023年3月6日) ▪ https://www.boj.or.jp/paym/iso/iso_panel/data/isop230307e.pdf ◦ 2段階認証の設定 ▪ https://id.smt.docomo.ne.jp/src/utility/twostepauth_flow.html ◦ 購入手続き時の認証について ▪ https://onlineshop.smt.docomo.ne.jp/supports/purchase_info.html • 株式会社メルカリ ◦ ログイン方法（パスキーなし） ▪ https://help.jp.mercari.com/guide/articles/1873/ ◦ パスキーとは ▪ https://help.jp.mercari.com/guide/articles/1103/ 7つの認証器タイプ - 6. Appendix
163. 目次 164 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
164. 6-2. toBでの事例抜粋 - (交通・物流分野 ) 165 7つの認証器タイプ - 6. Appendix • 国土交通省 ◦ 航空分野における情報セキュリティ確保に係る安全ガイドライン第 6版 (2024年4月25日) ◦ 空港分野における情報セキュリティ確保に係る安全ガイドライン第 3版 (2024年4月25日) ◦ 鉄道分野における情報セキュリティ確保に係る安全ガイドライン第 5版 (2024年4月18日) ◦ 物流分野（貨物自動車運送）における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ◦ 物流分野（倉庫）における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ◦ 物流分野（船舶運航）における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月26日) ◦ 港湾分野における情報セキュリティ確保に係る安全ガイドライン第 1版 (2024年4月18日) ◦ 各ガイドラインの【 5.4.2 情報システム等のアクセス制御】 ▪ 多要素認証が必要とされている ▪ 特にパスワードリスト攻撃への対策が必要とされている ▪ SMSによる認証は国内において乗っ取り、成りすましに成功した事例があるとして、非推奨とされている 引用：「航空分野における情報セキュリティ確保に係る安全ガイドライン第 6版」 https://www.mlit.go.jp/koku/content/20240425-koku-CyberSecurity.pdf 「空港分野における情報セキュリティ確保に係る安全ガイドライン第 3版」 https://www.mlit.go.jp/koku/content/20240425-kuko-CyberSecurity.pdf 「鉄道分野における情報セキュリティ確保に係る安全ガイドライン第 5版」 https://www.mlit.go.jp/tetudo/content/001738865.pdf 「物流分野(貨物自動車運送 )における情報セキュリティ確保に係る安全ガイドライン第 1版」 https://www.mlit.go.jp/jidosha/content/001742060.pdf 「物流分野(倉庫)における情報セキュリティ確保に係る安全ガイドライン第 1版」 https://www.mlit.go.jp/jidosha/content/001742057.pdf 「物流分野(船舶運航)における情報セキュリティ確保に係る安全ガイドライン第 1版」 https://www.mlit.go.jp/maritime/content/001744764.pdf 「港湾分野における情報セキュリティ確保に係る安全ガイドライン第 1版」 https://www.mlit.go.jp/kowan/content/001738824.pdf
165. 6-2. toBでの事例抜粋 - (製造分野) 166 7つの認証器タイプ - 6. Appendix • 経済産業省 ◦ 工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 (2022年11月16日) ▪ 【3.2 ステップ2 セキュリティ対策の立案】 • 高強度のセキュリティが要求される場合には、多要素認証による対策が例示されている • 中強度のセキュリティが要求される場合には、単要素認証による対策が例示されている 引用：「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 」 https://www.meti.go.jp/policy/netsecurity/wg1/factorysystems_guideline_ver1.0.pdf
166. 6-2. toBでの事例抜粋 - (製造分野) 167 7つの認証器タイプ - 6. Appendix • IPA ◦ ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド (2023年7月) ▪ 【2.5. 「運用」段階】 • リモートアクセスでの不正アクセス防止の対策として多要素認証が例示されている • 所持情報として FIDOセキュリティキーが例示されている ◦ 制御システムのセキュリティリスク分析ガイド第 2版 (2023年3月) ▪ 【B.4.1. 制御システムの境界防御チェックシート】 • リモートアクセスする全てのユーザは、トークンベース認証等の強力な認証を要求されることが望ま しいとされている • 認証の例として、単純なパスワード、複雑なパスワード、多要素認証、トークン、生体認証、スマート カード等が例示されている 引用：「制御システムのセキュリティリスク分析ガイド第 2版」 https://www.ipa.go.jp/security/controlsystem/ug65p90000019bkg-att/begoj9000000hpm8.pdf 「ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド」 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2023/t6hhco000000ysp4-att/t6hhco000000z6en.pdf
167. 6-2. toBでの事例抜粋 - (製造分野) 168 7つの認証器タイプ - 6. Appendix • 一般社団法人日本建設業連合会 ◦ 建設現場ネットワークの構築と運用ガイドライン (2024年2月) ▪ 【 6.4. 利用デバイスと情報漏洩対策】 • 管理者によるシステムのアクセスにおいては、 IP制限や端末制限をかけることが望ましいとされてい る。 • どちらもできない場合は、多要素認証が情報漏洩対策の強化方法として例示されている • 個人アカウントの乗っ取りやパスワード流出対策として、多要素認証が例示されている 引用：「建設現場ネットワークの構築と運用ガイドライン」 https://www.nikkenren.com/publication/fl.php?fi=1416&f=202404_nwglcs.pdf
168. 6-2. toBでの事例抜粋 - (医療分野) 169 7つの認証器タイプ - 6. Appendix • 総務省・厚生労働省 ◦ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 2.0版(案) (2024年10月1日) ▪ 【5.1.5. リスク対応策の設計・評価 】 ▪ 【5.2.2. リスク対応】 ◦ 医療情報システムの安全管理に関するガイドライン第 6.0版(システム運用編 ) (2023年5月) ▪ 【 14.1.1 利用者の識別・認証】 ◦ 2027年度時点で稼働が想定される医療情報システムでは、多要素認証を採用することとしている ◦ 指定された者以外の入室が制限される区画の端末からのアクセスにおいては、当該区画への入場時と端末利用時を含 めて多要素認証に相当すると考えてよいとされている 引用：「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 2.0版(案) 」 https://www.soumu.go.jp/main_content/000970142.pdf 「医療情報システムの安全管理に関するガイドライン第 6.0版(システム運用編 ) 」 https://www.mhlw.go.jp/content/10808000/001112044.pdf
169. 6-2. toBでの事例抜粋 - (商取引・決済分野 ) 170 7つの認証器タイプ - 6. Appendix • PCI SCC (Payment Card Industry Security Standards Council) ◦ PCI-DSS v4.0.1 (2024年6月) ▪ 【要件 8： ユーザの識別とシステムコンポーネントへのアクセスの認証】 • 管理者、一般ユーザのシステムへの全てのアクセスは単要素認証が必須とされている • 特に重要なデータ環境への全てのアクセスは多要素認証が必須とされている • IPA ◦ ECサイト構築・運用セキュリティガイドライン (2023年3月16日) ▪ 【第2部 1. EC サイトの構築時及び運用時における講じるべきセキュリティ対策要件】 • 管理者画面や管理用ソフトへの接続は端末を制限した上で多要素認証を行うことが必須とされてい る 引用：「 PCI DSS v4.0.1 」 https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf 「 ECサイト構築・運用セキュリティガイドライン」 https://www.ipa.go.jp/security/guide/vuln/ps6vr7000000acvt-att/000109337.pdf
170. 6-2. toBでの事例抜粋 - (働き方関連 ) 171 7つの認証器タイプ - 6. Appendix • 総務省 ◦ テレワークセキュリティガイドライン第 5版 (2021年5月) ▪ 【第4章 2. システム・セキュリティ管理者が実施すべき対策】 • システム管理者においては、可能な限り多要素認証を強制することが対策として例示されている 引用：「テレワークセキュリティガイドライン第 5版」 https://www.soumu.go.jp/main_content/000752925.pdf
171. 目次 172 1. 背景・概要 2. 認証の定義 3. AALの定義 4. 7つの認証器 4-1. フィッシング耐性が ない認証器 4-2. フィッシング耐性が ある認証器 5. toB, toCでの事例 5-1. toBでの事例 5-2. toCでの事例 6. Appendix 6-1. 参考文献 6-2. toBでの事例抜粋 6-3. toCでの事例抜粋 7つの認証器タイプ
172. 6-3. toCでの事例抜粋 - (高額決済サービス ) 173 7つの認証器タイプ - 6. Appendix • 株式会社NTTドコモ ◦ ドコモオンラインショップ ▪ 機種変更、契約変更、アクセサリー購入の一部にて、パスキーでの認証が必須 • 株式会社メルカリ ◦ メルコイン ▪ パスキーの登録が必須 引用：「日本銀行決済機構局 「ISOパネル（第7回）生体認証技術の金融サービスへの活用 ―新しい国際標準 ISO 19092の概要と活用可能性 ―」パネルディスカッション～生体認証技術の活用と 展望」 https://onlineshop.smt.docomo.ne.jp/supports/purchase_info.html 「株式会社NTTドコモ購入手続き時の認証について」 https://onlineshop.smt.docomo.ne.jp/supports/purchase_info.html 「株式会社メルカリパスキーとは」 https://help.jp.mercari.com/guide/articles/1103/
173. 6-3. toCでの事例抜粋 - (商取引・決済分野 ) 174 7つの認証器タイプ - 6. Appendix • IPA ◦ ECサイト構築・運用セキュリティガイドライン (2023年3月16日) ▪ 【第2部 1. EC サイトの構築時及び運用時における講じるべきセキュリティ対策要件】 • 成りすましなどによる不正ログインが行われる可能性が高い (ある)と判断した場合には、サイト利用 者のログイン時に多要素認証を導入することが必要とされている • フィッシング対策協議会 ◦ 利用者向けフィッシング詐欺対策ガイドライン (2024年度版) ▪ 【 4.5.2 サービス事業者が提供するセキュリティ機能を積極的に利用する】 • SMS認証やワンタイムパスワード認証などの多要素認証を積極的に利用することが推奨されてい る 引用：「 ECサイト構築・運用セキュリティガイドライン」 https://www.ipa.go.jp/security/guide/vuln/ps6vr7000000acvt-att/000109337.pdf 「利用者向けフィッシング詐欺対策ガイドライン」 https://www.antiphishing.jp/report/consumer_antiphishing_guideline_2024.pdf
174. 6-3. toCでの事例抜粋 - (商取引・決済分野 ) 175 7つの認証器タイプ - 6. Appendix • 一般社団法人日本クレジット協会 ◦ クレジットカード・セキュリティガイドライン 5.0 版 (2024年3月14日) ▪ 【 5-1-3-1 不正利用対策】 • カード会社は 2025年3月末時点で、 EMV 3-D セキュア登録会員が「静的 (固定)パスワード」から「動 的(ワンタイム )パスワード等」へ 100%の移行率になるよう取組むこととされている • 株式会社メルカリ ◦ メルカリ ▪ パスワード + SMS での2要素認証が可能 引用：「株式会社メルカリログイン方法（パスキーなし） 」 https://help.jp.mercari.com/guide/articles/1873/ 「クレジットカード・セキュリティガイドライン」 https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines_5.0_published.pdf
175. 6-3. toCでの事例抜粋 - (医療分野) 176 7つの認証器タイプ - 6. Appendix • 厚生労働省 ◦ 医療情報システムの安全管理に関するガイドライン第 6.0版 (2023年5月) ▪ 【7.2.2 患者等に診療情報等を提供する場合の外部からのアクセス】 • 患者等に診療情報等を提供したり参照閲覧させたりする場合においても、職員による外部アクセス と同等の対策を講じることが求められている • つまり、2027年度時点で稼働が想定される医療情報システムでは、患者によるアクセスでも多要素 認証が必要となる 引用：「医療情報システムの安全管理に関するガイドライン第 6.0版(システム運用編) 」 https://www.mhlw.go.jp/content/10808000/001112044.pdf
176. © OpenID Foundation Japan 登壇者紹介 177 持田 捷宏（LINEヤフー株式会社） これからIDを学びたい方でもわかるよう ミスリードがないように資料を作成しました IDに興味を持って正しく学ぶきっかけになれば幸いです 認証担当
177. © OpenID Foundation Japan パスキー深掘り 178
178. © OpenID Foundation Japan 参考文献 出典元を明確にして 後日詳細を確認できるようにする 179
179. © OpenID Foundation Japan 参考文献と注意事項 180 # パスキー深掘り - 参考文献 参考文献 FIDOアライアンス W3C 注記 詳細を確認する際には一次情報をご参照ください
180. © OpenID Foundation Japan はじめに 181 # パスキー深掘り • このセクションでは以下の定義で用語を扱います ◦ ID：デジタルアイデンティティ ◦ ログイン：認証+サービスを継続利用できるための処理 • 用語についての詳細な説明は実装パートで実施します • 本日はまとめた資料の一部をピックアップして発表します。全貌につ きましては公開される資料をご確認ください。
181. © OpenID Foundation Japan UX 【目的】 パスキーを導入する上で どういったUXが提供できるのか 理解する 【聞き手】 パスキーの導入を検討している 開発者 182
182. © OpenID Foundation Japan デザインガイドライン | Passkey Central 183 # パスキー深掘り - UX ◼パスキー・セントラル FIDOアライアンスにより作成され パスキーの導入や運用に関する情報が集約されている ◼デザインガイドライン 調査により策定したパスキーに関するUXについて紹介されている 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
183. © OpenID Foundation Japan パスキー作成の UXパターン 184 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
184. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 185 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
185. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 186 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 認証器に渡すI/F パスキー作成要求に対する 成果物 ＊Attestationについては 次のスライドで説明します パスキー作成に必要な情報
186. © OpenID Foundation Japan アテステーションとアサーション 187 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 # Attestation Generally, attestation is a statement that serves to bear witness, confirm, or authenticate. In the WebAuthn context, attestation is employed to provide verifiable evidence as to the origin of an authenticator and the data it emits. # Assertion The cryptographically signed AuthenticatorAssertionResponse object returned by an authenticator as the result of an authenticatorGetAssertion operation. 引用元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft アテステーション, Attestation 特定の認証器が作成したデータであるという検証可能な証拠 パスキー作成時に生成される アサーション, Assertion 認証器が作成する秘密鍵で署名されたオブジェクト パスキー認証時に生成される
187. © OpenID Foundation Japan これまでの認証の UX 188 # パスキー深掘り - UX ログイン画面上に ID識別子/パスワードの入力フォームがあり ID識別子/パスワードを入力して ログインボタンをクリックするUX ＊パスワードマネージャーを利用する場合 　Autofillで認証するUXになる サンプルサービス ログイン メールアドレス ログイン パスワード
188. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 189 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com
189. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 190 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com パスキー認証導入後 ユーザーにパスキー認証を利用してもらうためにも 親しみのある UXの中でパスキー認証を提供する 工夫が必要になる
190. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 191 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
191. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 192 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
192. © OpenID Foundation Japan ConditionalUI（シーケンス図） 193 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する パスキー認証に必要な情報 認証器に渡すI/F パスキー認証要求に対する 成果物
193. © OpenID Foundation Japan 【目的】 UXのセッションで説明したUXを 提供するための実装を理解する インターフェースの説明にフォーカスし ています 具体的な処理について触れません 実装 194
194. © OpenID Foundation Japan ブラウザ↔認証器↔ユーザーの I/F 195 # パスキー深掘り - 実装 ◼パスキー作成 navigator.credentials.create({ "publicKey": options(*) }) *PublicKeyCredentialCreationOptions ◼パスキー認証 navigator.credentials.get({ "publicKey": options(*) }) *PublicKeyCredentialRequestOptions 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
195. © OpenID Foundation Japan PublicKeyCredentialCreationOptions（全体像） 196 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
196. © OpenID Foundation Japan rp - フィッシング耐性がある理由 197 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions PublicKeyCredentialに紐づけるRP情報 項目 概要 name 表示目的のユーザーが識別できる RPの名前。 id RPの識別子。実態としては RPのdomain。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft PublicKeyCredentialには作成時のRPのdomain（rp.id）が紐づいている。 認証器が扱えるPublicKeyCredentialはrp.idにより制限されている。 フィッシングサイトがホスティングされているdomainと正規のRPのdomainは一致せ ず、フィッシングサイトで正規のRPで作成されたPublicKeyCrendentialを使用すること はできない。 →フィッシング耐性がある
197. © OpenID Foundation Japan authenticatorSelection - パスキー作成時に必要な項目 198 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions RPが認証器に対して要求するCredential作成時の要件 項目 概要 authenticatorAttachment ブラウザがどう認証器とやりとりして PublicKeyCredentialが生成、使用されるか。 デバイスから取り除くことができない認証器経由の場合 「platform」。 デバイスから取り除くことができる認証器経由の場合 「cross-platform」。 residentKey パスキー（ディスカバラブルFIDOクレデンシャル）の作成を要求するか。 パスキーの作成を強制する場合は 「required」。（requireResidentKeyがtrueの場合デフォルト値） パスキーの作成ができない場合を許容する場合は 「preferred」。 パスキーの作成を拒否する場合は 「discouraged」。（requireResidentKeyがtrue以外の場合デフォルト値） requireResidentKey パスキーの作成を強制する場合 「true」。強制しない場合 「false（デフォルト値）」。 WebAuthnLevel1との後方互換のための項目。 userVerification ユーザー検証を要求するか。 ユーザー検証を強制する場合は 「required」。 ユーザー検証できない場合を許容する場合は 「preferred（デフォルト値）」。 ユーザー検証をしないことを強制する場合は 「discouraged」。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
198. © OpenID Foundation Japan PublicKeyCredentialRequestOptions（全体像） 199 # パスキー深掘り - 実装 - パスキー認証 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 必須 指定する情報 challenge ✔ リプレイ攻撃対策用のchallenge timeout 認証器が処理をキャンセル扱いするまでの時間（ms） rpId PublicKeyCredentialを利用するRPのdomain allowCredentials PRが保存しているユーザーのPublicKeyCredential一覧 userVerification ユーザー検証可能な認証器のみを要求するか否か hints PublicKeyCredentialを利用する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証器に依頼する追加の処理
199. © OpenID Foundation Japan ConditionalUIを提供に必要な項目 200 # パスキー深掘り - 実装 - パスキー認証 ◼allowCredentials RPで保存しているユーザーに紐づくPublicKeyCredential一覧 • ConditionalUIを提供する際にはallowCredentialsを空にする • allowCredentialsを空にした場合、認証器自身が利用可能なパス キーを探す。 ◦ この時利用可能なのは パスキー（ディスカバラブルFIDOクレデンシャル）のみ。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
200. © OpenID Foundation Japan ConditionalUIを提供するための実装 201 ◼HTML • inputタグの autocomplete に webauthn を追加する ◦ ID識別子: autocomplete=”username webauthn” ◦ パスワード: autocomplete=”current-password webauthn” ◼JavaScript • ConditionalUIに対応しているか確認する ◦ PublicKeyCredential.isConditionalMediationAvailable() • ConditionalUIに対応していれば navigator.credentials.get({ mediation:'conditional’, publicKey:options }) を実行する ◦ options の allowCredentials を空配列にする # パスキー深掘り - 実装 - パスキー認証 参考元：「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
201. © OpenID Foundation Japan まとめ パスキー深掘り 202
202. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 203 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
203. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 204 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
204. © OpenID Foundation Japan 活動報告会でいただいたご質問への回答 205 # パスキー深掘り Q: パスキーを導入する際にOSやブラウザ固有の仕様を知る方法につ いてアドバイスがあれば教えほしいです。 A: 実機を触っていただく、passkeys.dev*をご確認いただく方法が良い と思います。 *「passkeys.dev - Device Support」https://passkeys.dev/device-support/
205. © OpenID Foundation Japan 以降、資料の全貌になります。 206
206. © OpenID Foundation Japan UX 【目的】 パスキーを導入する上で どういったUXが提供できるのか 理解する 【聞き手】 パスキーの導入を検討している 開発者 207
207. © OpenID Foundation Japan UX パスキー作成 208 セッションの構成 • ID管理画面で作成 ◦ UIイメージ ◦ シーケンス図 • 訴求画面で作成 ◦ UIイメージ ◦ シーケンス図 • 新規ID作成と同時に作成 ◦ UIイメージ ◦ シーケンス図
208. © OpenID Foundation Japan デザインガイドライン | Passkey Central 209 # パスキー深掘り - UX ◼パスキー・セントラル FIDOアライアンスにより作成され パスキーの導入や運用に関する情報が集約されている ◼デザインガイドライン 調査により策定したパスキーに関するUXについて紹介されている 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
209. © OpenID Foundation Japan パスキー作成の UXパターン 210 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
210. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 211 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
211. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 212 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 認証器に渡すI/F パスキー作成要求に対する 成果物 ＊Attestationについては 次のスライドで説明します パスキー作成に必要な情報
212. © OpenID Foundation Japan アテステーションとアサーション 213 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 # Attestation Generally, attestation is a statement that serves to bear witness, confirm, or authenticate. In the WebAuthn context, attestation is employed to provide verifiable evidence as to the origin of an authenticator and the data it emits. # Assertion The cryptographically signed AuthenticatorAssertionResponse object returned by an authenticator as the result of an authenticatorGetAssertion operation. 引用元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft アテステーション, Attestation 特定の認証器が作成したデータであるという検証可能な証拠 パスキー作成時に生成される アサーション, Assertion 認証器が作成する秘密鍵で署名されたオブジェクト パスキー認証時に生成される
213. © OpenID Foundation Japan パスキー作成の UXパターン 214 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
214. © OpenID Foundation Japan 既存の認証方法で認証後パスキーを作成する 訴求画面でパスキー作成 （UIイメージ） 215 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 ログイン user@example.com サンプルサービス ログイン メールアドレス サンプルサービス サンプルサービス パスキー作成完了 ******** パスワード パスキー パスキーの説明 … … … パスキー作成 あとで サンプルサービス パスキー パスキーの説明 … … … パスキー作成 あとで パスキーを 作成しますか？ 次へ パスキー管理画面 OK 参考元：「SMS OTPを廃止する | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/deprecate-sms-otp
215. © OpenID Foundation Japan 訴求画面でパスキー作成 （シーケンス図） 216 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存の認証方法で認証後パスキーを作成する
216. © OpenID Foundation Japan パスキー作成の UXパターン 217 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
217. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （UIイメージ） 218 # パスキー深掘り - UX - パスキー作成の UXパターン - 新規IDに対するパスキー作成 ユーザーにID識別子を入力してもらいパスキーを作成する 次へ サンプルサービス ログイン / 新規ID作成 メールアドレス 新規作成 user@example.com サンプルサービス 新規ID作成 下記メールアドレスで IDを作 成します 新規作成 user@example.com サンプルサービス 新規ID作成 下記メールアドレスで IDを作 成します user@example.com パスキーを 作成しますか？ 次へ ID管理画面 user@example.com サンプルサービス 新規ID作成完了 メールアドレス X 参考元：「パスキーを使用した新しいアカウント作成 | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/new-account-creation-with-a-passkey
218. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （シーケンス図） 219 # パスキー深掘り - UX - パスキー作成の UXパターン - 新規IDに対するパスキー作成 ユーザーにID識別子を入力してもらいパスキーを作成する
219. © OpenID Foundation Japan セッションの構成 • パスワード認証 • ConditionalUI ◦ UIイメージ ◦ シーケンス図 • ワンボタンクリック ◦ UIイメージ ◦ シーケンス図 UX パスキー認証 220
220. © OpenID Foundation Japan これまでの認証の UX 221 # パスキー深掘り - UX ログイン画面上に ID識別子/パスワードの入力フォームがあり ID識別子/パスワードを入力して ログインボタンをクリックするUX ＊パスワードマネージャーを利用する場合 　Autofillで認証するUXになる サンプルサービス ログイン メールアドレス ログイン パスワード
221. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 222 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com
222. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 223 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com パスキー認証導入後 ユーザーにパスキー認証を利用してもらうためにも 親しみのある UXの中でパスキー認証を提供する 工夫が必要になる
223. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 224 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
224. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 225 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI なぜ登場したのか
225. © OpenID Foundation Japan WebAuthnの認証のプライバシー 226 # パスキー深掘り - UX - パスキー認証の UXパターン - ConditionalUIの背景 ユーザーの同意なしに RPにパスキーを識別されることを防ぐ 具体的には • パスキーを利用できない • パスキーを利用できるが利用に関して同意していない この2つの違いを識別できないようにする 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft パスキーを利用できるかどうかは ユーザーに同意を取るまで RPで判断できない
226. © OpenID Foundation Japan パスキーを利用する際の同意 227 # パスキー深掘り - UX - パスキー認証の UXパターン - ConditionalUIの背景 WebAuthnでFIDO2のための拡張が定義されている navigator.credentials.getというJavaScriptのAPIを呼び出して 認証器経由でユーザーに同意を取る navigator.credentials.get({ "publicKey": options }) .then(function (assertion) { // Send assertion to server for verification }).catch(function (err) { // No acceptable credential or user refused consent. Handle appropriately. }); 引用元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
227. © OpenID Foundation Japan ConditionalUIの背景 228 # パスキー深掘り - UX - パスキー認証の UXパターン - ConditionalUIの背景 WebAuthnで定義されているプライバシーの関係上RPは 「パスキーを利用できるかもしれないのでパスキー認証を発火させてみ る」という対応しかできない パスキーを利用できない場合ユーザーに混乱を招きうる体験になってし まう課題感があった 参考元：「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI パスキーを利用できればパスキーを利用する パスキーを利用できなければ別の認証方法を利用する 認証のUXを提供することで解決している
228. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 229 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI 再掲
229. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 230 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
230. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 231 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
231. © OpenID Foundation Japan ConditionalUI（シーケンス図） 232 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する パスキー認証に必要な情報 認証器に渡すI/F パスキー認証要求に対する 成果物
232. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 233 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
233. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 234 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
234. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 235 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel
235. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 236 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください
236. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 237 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください パスワードを扱わないログイン画面 パスワードを扱わないのでログイン画面から ID識別子/パスワードの入力フォームがなくなり ユーザーがフィッシングサイトに ID識別子/パスワードを入力してしまうリスクが なくなる
237. © OpenID Foundation Japan ボタンクリック（＋生体認証）で認証するUX ワンボタンクリック（シーケンス図） 238 # パスキー深掘り - UX - パスキー認証の UXパターン
238. © OpenID Foundation Japan 【目的】 UXのセッションで説明したUXを 提供するための実装を理解する インターフェースの説明にフォーカスし ています 具体的な処理について触れません 実装 239
239. © OpenID Foundation Japan ブラウザ↔認証器↔ユーザーの I/F 240 # パスキー深掘り - 実装 ◼パスキー作成 navigator.credentials.create({ "publicKey": options(*) }) *PublicKeyCredentialCreationOptions ◼パスキー認証 navigator.credentials.get({ "publicKey": options(*) }) *PublicKeyCredentialRequestOptions 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
240. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 241 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 再掲
241. © OpenID Foundation Japan ConditionalUI（シーケンス図） 242 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する 再掲
242. © OpenID Foundation Japan 実装 セッションの構成 • ID管理画面で作成 ◦ UIイメージ ◦ シーケンス図 ▪ I/Fの説明 • 訴求画面で作成 ◦ 差分なし • 新規ID作成と同時に作成 ◦ 差分なし パスキー作成 243
243. © OpenID Foundation Japan パスキー作成の UXパターン 244 # パスキー深掘り - UX 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/ 再掲 • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊これから説明する実装がどの UXについての説 明になるのか UXを振り返ります
244. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 245 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings 再掲
245. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 246 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 再掲 ＊四角で囲まれた I/Fについて説明していきます
246. © OpenID Foundation Japan パラメータの詳細説明 247 # パスキー深掘り - 実装 • RPで保存が推奨される PublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成されるPublicKeyCredentialの詳細
247. © OpenID Foundation Japan RPで保存が推奨される PublicKeyCredentialの情報 248 # パスキー深掘り - 実装 パスキー作成時に作成されるAttestation用のPublicKeyCredentialに 関する情報 項目 概要 type 鍵のタイプ(public-key固定) id PublicKeyCredentialの識別子 publicKey 認証器内の秘密鍵とペアの公開鍵 signCount 認証器が保持する最新の Assertion回数 transports getTransportsで取得できるtransportsの値 uvInitialized ユーザー検証済みかどうかの boolean backupEligible PublicKeyCrednetialが同期されることが 許可されているか可能か否か backupState PublicKeyCrednetialが現在同期されているか否か attestationObject (optional) attestationClientDataJSON (optional) 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft それぞれの項目が なぜ必要なのか 以降のスライドで説明します
248. © OpenID Foundation Japan パラメータの詳細説明 249 # パスキー深掘り - 実装 • RPで保存が推奨されるPublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成されるPublicKeyCredentialの詳細
249. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 250 # パスキー深掘り - 実装 - パスキー作成 ブラウザを介して認証器に対して Attestaion用のPublicKeyCredentialの作成を依頼する時に navigator.credentials.createに渡すoptions 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
250. © OpenID Foundation Japan PublicKeyCredentialCreationOptions（全体像） 251 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
251. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 252 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 下記内容に関連する項目に絞り説明します ・フィッシング耐性 /リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
252. © OpenID Foundation Japan rp - フィッシング耐性がある理由 253 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions PublicKeyCredentialに紐づけるRP情報 項目 概要 name 表示目的のユーザーが識別できる RPの名前。 id RPの識別子。実態としては RPのdomain。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft PublicKeyCredentialには作成時のRPのdomain（rp.id）が紐づいている。 認証器が扱えるPublicKeyCredentialはrp.idにより制限されている。 フィッシングサイトがホスティングされているdomainと正規のRPのdomainは一致せ ず、フィッシングサイトで正規のRPで作成されたPublicKeyCrendentialを使用すること はできない。 →フィッシング耐性がある
253. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 254 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 下記内容に関連する項目に絞り説明します ・フィッシング耐性 /リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
254. © OpenID Foundation Japan user - ConditionalUIで参照される項目 255 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions PublicKeyCredentialに紐づけるユーザー情報 項目 概要 name 人間が理解しやすいユーザーの名前。優先されて利用される。 id 認証器内におけるユーザー識別子。 （最大サイズが 64 バイトのバイト シーケンス） ユーザーに表示されるものではない。 displayName 人間が理解しやすいユーザーの名前。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft ConditionalUIではuser.nameの値が優先して表示される
255. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 256 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲 ↑ここに表示される ユーザー名として user.nameが使用される
256. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 257 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 下記内容に関連する項目に絞り説明します ・フィッシング耐性 /リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
257. © OpenID Foundation Japan ランダムに生成されたArrayBuffer。 推測されないよう少なくとも16バイトである必要がある。 challenge - リプレイ攻撃耐性がある理由 258 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
258. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 259 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 rp ✔ PublicKeyCredentialに紐づけるPRの情報 user ✔ PublicKeyCredentialに紐づけるユーザー情報 challenge ✔ リプレイ攻撃対策用のchallenge pubKeyCredParams ✔ RPがサポートするPublicKeyCredentialの鍵のタイプと署名アルゴリズム timeout 認証器が処理をキャンセル扱いするまでの時間（ ms） excludeCredentials 重複を避けたいPublicKeyCredential一覧 authenticatorSelection RPが認証器に対して要求する Credential作成時の要件 hints PublicKeyCredentialを作成する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証機に依頼する追加の処理 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 下記内容に関連する項目に絞り説明します ・フィッシング耐性 /リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
259. © OpenID Foundation Japan authenticatorSelection - パスキー作成時に必要な項目 260 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredentialCreationOptions RPが認証器に対して要求するCredential作成時の要件 項目 概要 authenticatorAttachment ブラウザがどう認証器とやりとりして PublicKeyCredentialが生成、使用されるか。 デバイスから取り除くことができない認証器経由の場合 「platform」。 デバイスから取り除くことができる認証器経由の場合 「cross-platform」。 residentKey パスキー（ディスカバラブル FIDOクレデンシャル）の作成を要求するか。 パスキーの作成を強制する場合は 「required」。（requireResidentKeyがtrueの場合デフォルト値） パスキーの作成ができない場合を許容する場合は 「preferred」。 パスキーの作成を拒否する場合は 「discouraged」。（requireResidentKeyがtrue以外の場合デフォルト値） requireResidentKey パスキーの作成を強制する場合 「true」。強制しない場合 「false（デフォルト値）」。 WebAuthnLevel1との後方互換のための項目。 userVerification ユーザー検証を要求するか。 ユーザー検証を強制する場合は 「required」。 ユーザー検証できない場合を許容する場合は 「preferred（デフォルト値）」。 ユーザー検証をしないことを強制する場合は 「discouraged」。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
260. © OpenID Foundation Japan パラメータの詳細説明 261 # パスキー深掘り - 実装 • RPで保存が推奨されるPublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成される PublicKeyCredentialの詳細
261. © OpenID Foundation Japan PublicKeyCredential（全体像） 262 # パスキー深掘り - 実装 - パスキー作成 options に基づき認証器が生成する属性を含むObject 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 id PublicKeyCredentialの識別子をBase64urlエンコードした値。 rawId PublicKeyCredentialの識別子。 response （navigator.credentials.createの場合）PublicKeyCredentialの作成に対するレスポンス。 （navigator.credentials.getの場合）PublicKeyCredentialの使用に対するレスポンス。 authenticatorAttachment ブラウザがどう認証器とやりとりしてPublicKeyCredentialが作成されたのか。 getClientExtensionResults() extentionsで指定した項目に関する結果を取得するI/F。 isConditionalMediationAvailable() ConditionalUIが利用可能なPublicKeyCredentialか確認するStaticなI/F。 toJSON() （navigator.credentials.createの場合）RegistrationResponseJSONを返却するI/F。 （navigator.credentials.getの場合）AuthenticationResponseJSONを返却するI/F。
262. © OpenID Foundation Japan PublicKeyCredential - id 263 # パスキー深掘り - 実装 - パスキー作成 options 基づき認証器が生成するObject 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 id PublicKeyCredentialの識別子をBase64urlエンコードした値。 rawId PublicKeyCredentialの識別子。 response （navigator.credentials.createの場合）PublicKeyCredentialの作成に対するレスポンス。 （navigator.credentials.getの場合）PublicKeyCredentialの使用に対するレスポンス。 authenticatorAttachment ブラウザがどう認証器とやりとりしてPublicKeyCredentialが作成されたのか。 getClientExtensionResults() extentionsで指定した項目に関する結果を取得するI/F。 isConditionalMediationAvailable() ConditionalUIが利用可能なPublicKeyCredentialか確認するStaticなI/F。 toJSON() （navigator.credentials.createの場合）RegistrationResponseJSONを返却するI/F。 （navigator.credentials.getの場合）AuthenticationResponseJSONを返却するI/F。 ◼id パスキー認証の際に 作成された PublicKeyCredentialが どのPublicKeyCredentialで作成されたかを特定する際に利用される 下記内容に関連する項目に絞り説明します ・フィッシング耐性/リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
263. © OpenID Foundation Japan PublicKeyCredential - isConditionalMediationAvailable() 264 # パスキー深掘り - 実装 - パスキー作成 options 基づき認証器が生成するObject 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 id PublicKeyCredentialの識別子をBase64urlエンコードした値。 rawId PublicKeyCredentialの識別子。 response （navigator.credentials.createの場合）PublicKeyCredentialの作成に対するレスポンス。 （navigator.credentials.getの場合）PublicKeyCredentialの使用に対するレスポンス。 authenticatorAttachment ブラウザがどう認証器とやりとりしてPublicKeyCredentialが作成されたのか。 getClientExtensionResults() extentionsで指定した項目に関する結果を取得するI/F。 isConditionalMediationAvailable() ConditionalUIが利用可能なPublicKeyCredentialか確認するStaticなI/F。 toJSON() （navigator.credentials.createの場合）RegistrationResponseJSONを返却するI/F。 （navigator.credentials.getの場合）AuthenticationResponseJSONを返却するI/F。 ◼isConditionalMediationAvailable() ConditionalUIのUXを提供する際に 利用している OS,ブラウザで ConditionalUIを利用可能かどうか 確認する際に利用する Staticなインターフェース
264. © OpenID Foundation Japan PublicKeyCredential - response 265 # パスキー深掘り - 実装 - パスキー作成 options 基づき認証器が生成するObject 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 id PublicKeyCredentialの識別子をBase64urlエンコードした値。 rawId PublicKeyCredentialの識別子。 response （navigator.credentials.createの場合）PublicKeyCredentialの作成に対するレスポンス。 （navigator.credentials.getの場合）PublicKeyCredentialの使用に対するレスポンス。 authenticatorAttachment ブラウザがどう認証器とやりとりしてPublicKeyCredentialが作成されたのか。 getClientExtensionResults() extentionsで指定した項目に関する結果を取得するI/F。 isConditionalMediationAvailable() ConditionalUIが利用可能なPublicKeyCredentialか確認するStaticなI/F。 toJSON() （navigator.credentials.createの場合）RegistrationResponseJSONを返却するI/F。 （navigator.credentials.getの場合）AuthenticationResponseJSONを返却するI/F。 次のスライド以降で詳しく説明していきます
265. © OpenID Foundation Japan response - パスキー作成時（全体像） 266 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential パスキー作成の際に生成されるPublicKeyCredentialのresponse 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 clientDataJSON RPの情報とブラウザの情報を集約した Object。 attestationObject Attestation。 getTransports() transportsを取得するI/F。 getAuthenticatorData() 認証器のPublicKeyCredentialの作成に関する情報を取得する I/F。 getPublicKey() 公開鍵を取得するI/F。 getPublicKeyAlgorithm() 署名/検証のアルゴリズムを示す識別子を取得する I/F。 RPで保存が推奨される PublicKeyCredentialの情報 が格納される項目に絞り説明します
266. © OpenID Foundation Japan パスキー作成時に生成される PublicKeyCredential の response に含まれる attestationObject の項目で Authenticator Data と Attestation Statement が含まれる CBOR*エンコードされたオブジェクト。 *CTAP2で定義されているCompact Binary Object Representation attestationObject 267 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response 参照元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
267. © OpenID Foundation Japan Authenticator Data - rpIdHash 268 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject 認証器の PublicKeyCredential の作成の処理に関する情報 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 rpIdHash rp.idをSHA-256でハッシュ化したバイト列。 flags PublicKeyCredentialに関する情報がBit列で格納される。 signCount 認証器がカウントアップする Assertionの回数。 attestedCredentialData (optional) 公開鍵などが格納される。 extensions (optional) extentsに指定した処理の結果が格納される。 rpIdHashをRPで検証することで 認証器による制御のみならず RPでもフィッシング検知可能な仕様になっている
268. © OpenID Foundation Japan Authenticator Data - signCount 269 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject 認証器の PublicKeyCredential の作成の処理に関する情報 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 rpIdHash rp.idをSHA-256でハッシュ化したバイト列。 flags PublicKeyCredentialに関する情報がBit列で格納される。 signCount 認証器がカウントアップする Assertionの回数。 attestedCredentialData (optional) 公開鍵などが格納される。 extensions (optional) extentsに指定した処理の結果が格納される。 パスキー認証の際に発行される PublicKeyCredentialのsignCountが RPで保存済みの PublicKeyCredentialのsignCountと 同じもしくは小さい場合、 RPはリスク判定に利用することができる
269. © OpenID Foundation Japan Authenticator Data - flags 270 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject 認証器の PublicKeyCredential の作成の処理に関する情報 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 rpIdHash rp.idをSHA-256でハッシュ化したバイト列。 flags PublicKeyCredentialに関する情報がBit列で格納される。 signCount 認証器がカウントアップする Assertionの回数。 attestedCredentialData (optional) 公開鍵などが格納される。 extensions (optional) extentsに指定した処理の結果が格納される。 次のスライド以降で説明していきます
270. © OpenID Foundation Japan Authenticator Data - flags 271 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject Bit 0: UserPresent (UP) : ユーザー存在確認結果(1:成功) Bit 1: 将来的に利用するためのbit（現状値に意味を持たない） Bit 2: User Verified (UV) : ユーザー検証(認証器とユーザーとのやり取り )結果(1:成功) Bit 3: Backup Eligibility (BE) : PublicKeyCrednetialが同期可能か否か (1:可能) Bit 4: Backup State (BS) : PublicKeyCrednetialが現状同期されているか否か (1:同期済み) Bit 5: 将来的に利用するためのbit（現状値に意味を持たない） Bit 6: Attested credential data included (AT) : attested credential dataが含まれてるか否か Bit 7: Extension data included (ED) : extensionsが含まれている否か 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
271. © OpenID Foundation Japan Authenticator Data - flags 272 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject Bit 0: UserPresent (UP) : ユーザー存在確認結果(1:成功) Bit 1: 将来的に利用するためのbit（現状値に意味を持たない） Bit 2: User Verified (UV) : ユーザー検証(認証器とユーザーとのやり取り )結果(1:成功) Bit 3: Backup Eligibility (BE) : PublicKeyCrednetialが同期可能か否か (1:可能) Bit 4: Backup State (BS) : PublicKeyCrednetialが現状同期されているか否か (1:同期済み) Bit 5: 将来的に利用するためのbit（現状値に意味を持たない） Bit 6: Attested credential data included (AT) : attested credential dataが含まれてるか否か Bit 7: Extension data included (ED) : extensionsが含まれている否か 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft UV,BE,BSフラグを用いて パスキー管理画面で当該パスキーの同期情報として表示する等 RPのビジネス要件を満たす振る舞いを選択できる
272. © OpenID Foundation Japan attestedCredentialData - 公開鍵が格納される 273 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response - attestationObject パスキー作成時に生成される PublicKeyCredential の response の attestationObject の Authenticator Data の中にある attestedCredentialData の構造 項目 概要 aaguid 認証器の製造元とモデルを一意に識別する値 credentialIdLength credentialIdのバイトサイズ credentialId PublicKeyCredentialの識別子 credentialPublicKey COSE_Keyフォーマットでエンコーディングされた 公開鍵 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
273. © OpenID Foundation Japan transports 274 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential アサーションを取得する方法に関するヒント 値 概要 usb 取り外し可能なUSB経由 nfc Near Field Communication (NFC) 経由 ble Bluetooth Smart (Bluetooth Low Energy / BLE) 経由 smart-card 連絡先が付与された ISO/IEC 7816準拠のスマートカード経由 hybrid データ転送メカニズムと近接メカニズムの組み合わせ internal 取り外し不可能なデバイス固有の経路 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft パスキー認証の際に使用する PublicKeyCredentialが どの方法で利用可能なのかを 認証器に伝えるために利用する
274. © OpenID Foundation Japan 実装 セッションの構成 • ConditionalUI ◦ UIイメージ ◦ シーケンス図 ▪ I/F説明 • ワンボタンクリック ◦ UIイメージ ◦ シーケンス図 ▪ I/F説明 パスキー認証 275
275. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 276 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI 再掲 ＊これから説明する実装がどの UXについ ての説明になるのか UXを振り返ります
276. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 277 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲
277. © OpenID Foundation Japan ConditionalUI（シーケンス図） 278 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する 再掲 ＊四角で囲まれた I/Fについて説明していきます
278. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 279 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel 再掲
279. © OpenID Foundation Japan ボタンクリック（＋生体認証）で認証するUX ワンボタンクリック（シーケンス図） 280 # パスキー深掘り - UX - パスキー認証の UXパターン 再掲 ＊四角で囲まれた I/Fについて 説明していきます
280. © OpenID Foundation Japan パラメータの詳細説明 281 # パスキー深掘り - 実装 • PublicKeyCredentialRequestOptionsの詳細 ◦ navigator.credentials.getに渡すoptions • 作成されるPublicKeyCredentialの詳細
281. © OpenID Foundation Japan PublicKeyCredentialRequestOptions 282 # パスキー深掘り - 実装 - パスキー認証 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft ブラウザを介して認証器に対して Assertion用のPublicKeyCredentialの作成を依頼する際に navigator.credentials.getに渡すoptions
282. © OpenID Foundation Japan PublicKeyCredentialRequestOptions（全体像） 283 # パスキー深掘り - 実装 - パスキー認証 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 必須 指定する情報 challenge ✔ リプレイ攻撃対策用のchallenge timeout 認証器が処理をキャンセル扱いするまでの時間（ms） rpId PublicKeyCredentialを利用するRPのdomain allowCredentials PRが保存しているユーザーのPublicKeyCredential一覧 userVerification ユーザー検証可能な認証器のみを要求するか否か hints PublicKeyCredentialを利用する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証器に依頼する追加の処理
283. © OpenID Foundation Japan PublicKeyCredentialRequestOptions 284 # パスキー深掘り - 実装 - パスキー認証 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 必須 指定する情報 challenge ✔ リプレイ攻撃対策用のchallenge timeout 認証器が処理をキャンセル扱いするまでの時間（ms） rpId PublicKeyCredentialを利用するRPのdomain allowCredentials PRが保存しているユーザーのPublicKeyCredential一覧 userVerification ユーザー検証可能な認証器のみを要求するか否か hints PublicKeyCredentialを利用する認証器のタイプ attestation Attestationの送信方法 attestationFormats Attestationのフォーマット extensions 認証器に依頼する追加の処理 下記内容に関連する項目に絞り説明します ・フィッシング耐性 /リプレイ耐性がある理由 ・公開鍵暗号方式が導入されている箇所 ・パスキー作成の際に指定すべき項目 ・ConditionalUIで参照される項目
284. © OpenID Foundation Japan ConditionalUIを提供に必要な項目 285 # パスキー深掘り - 実装 - パスキー認証 ◼allowCredentials RPで保存しているユーザーに紐づくPublicKeyCredential一覧 • ConditionalUIを提供する際にはallowCredentialsを空にする • allowCredentialsを空にした場合、認証器自身が利用可能なパス キーを探す。 ◦ この時利用可能なのは パスキー（ディスカバラブルFIDOクレデンシャル）のみ。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft
285. © OpenID Foundation Japan ConditionalUIを提供するための実装 286 ◼HTML • inputタグの autocomplete に webauthn を追加する ◦ ID識別子: autocomplete=”username webauthn” ◦ パスワード: autocomplete=”current-password webauthn” ◼JavaScript • ConditionalUIに対応しているか確認する ◦ PublicKeyCredential.isConditionalMediationAvailable() • ConditionalUIに対応していれば navigator.credentials.get({ mediation:'conditional’, publicKey:options }) を実行する ◦ options の timeout は指定しない ◦ options の allowCredentials を空配列にする # パスキー深掘り - 実装 - パスキー認証 参考元：「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI
286. © OpenID Foundation Japan パラメータの詳細説明 287 # パスキー深掘り - 実装 • PublicKeyCredentialRequestOptionsの詳細 ◦ navigator.credentials.getに渡すoptions • 作成される PublicKeyCredentialの詳細
287. © OpenID Foundation Japan PublicKeyCredential（全体像） 288 options に基づき認証器が生成する属性を含むObject # パスキー深掘り - 実装 - パスキー作成 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft 項目 概要 id PublicKeyCredentialの識別子をBase64urlエンコードした値。 rawId PublicKeyCredentialの識別子。 response （navigator.credentials.createの場合）PublicKeyCredentialの作成に対するレスポンス。 （navigator.credentials.getの場合）PublicKeyCredentialの使用に対するレスポンス。 authenticatorAttachment ブラウザがどう認証器とやりとりしてPublicKeyCredentialが作成されたのか。 getClientExtensionResults() extentionsで指定した項目に関する結果を取得するI/F。 isConditionalMediationAvailable() ConditionalUIが利用可能なPublicKeyCredentialか確認するStaticなI/F。 toJSON() （navigator.credentials.createの場合）RegistrationResponseJSONを返却するI/F。 （navigator.credentials.getの場合）AuthenticationResponseJSONを返却するI/F。 再掲 パスキー作成時と違うのは responseとtoJSON()のみ
288. © OpenID Foundation Japan response - 公開鍵暗号方式で署名される項目 289 # パスキー深掘り - 実装 - パスキー認証 - PublicKeyCredential パスキー認証の際に生成されるPublicKeyCredentialのresponse 項目 概要 clientDataJSON RPの情報とブラウザの情報を集約した Object。 authenticatorData 認証器が生成するPublicKeyCredentialの関連情報。 signature authenticatorDataとClientDataHashを秘密鍵で署名した値。 userHandle 認証器から返却されるユーザーハンドルの値。 attestationObject (optional) 特定の認証器が作成したデータであるという検証可能な証拠。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft navigator.credentials.createで作成した認証器にしか保存されていない 秘密鍵と 対のRPで保存している公開鍵を用いて署名を検証する →RPで公開鍵が漏洩しても秘密鍵は漏洩しないのでパスキー認証は成立しない ＊clientDataJSONとauthenticatorDataの改ざんの検知も可能
289. © OpenID Foundation Japan clientDataJSON - リプレイ攻撃耐性 290 # パスキー深掘り - 実装 - パスキー作成 - PublicKeyCredential - response response の中に含まれる clientDataJSON の全体像 項目 概要 type 鍵のタイプ。署名混同攻撃 (攻撃者が正当な署名を別の署名に置き換える攻撃 ) 対策。 challenge リプレイ攻撃対策用の challenge。 origin PublicKeyCredential生成時のOrigin。 topOrigin PublicKeyCredential生成時のTLD。 crossOrigin PublicKeyCredential生成時にCrossOriginであったどうかのboolean。 参考元：「Web Authentication: An API for accessing Public Key Credentials - Level 3」https://www.w3.org/TR/webauthn-3/ Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and document use rules apply. Working Draft challeng等が改ざんされても署名検証で検知できる仕組みになっている
290. © OpenID Foundation Japan まとめ パスキー深掘り 291
291. © OpenID Foundation Japan パスキー作成の UXパターン 292 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/ 再掲
292. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 293 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings 再掲
293. © OpenID Foundation Japan 既存の認証方法で認証後パスキーを作成する 訴求画面でパスキー作成 （UIイメージ） 294 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 ログイン user@example.com サンプルサービス ログイン メールアドレス サンプルサービス サンプルサービス パスキー作成完了 ******** パスワード パスキー パスキーの説明 … … … パスキー作成 あとで サンプルサービス パスキー パスキーの説明 … … … パスキー作成 あとで パスキーを 作成しますか？ 次へ パスキー管理画面 OK 参考元：「SMS OTPを廃止する | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/deprecate-sms-otp 再掲
294. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （UIイメージ） 295 # パスキー深掘り - UX - パスキー作成の UXパターン - 新規IDに対するパスキー作成 ユーザーにID識別子を入力してもらいパスキーを作成する 次へ サンプルサービス ログイン / 新規ID作成 メールアドレス 新規作成 user@example.com サンプルサービス 新規ID作成 下記メールアドレスで IDを作 成します 新規作成 user@example.com サンプルサービス 新規ID作成 下記メールアドレスで IDを作 成します user@example.com パスキーを 作成しますか？ 次へ ID管理画面 user@example.com サンプルサービス 新規ID作成完了 メールアドレス X 参考元：「パスキーを使用した新しいアカウント作成 | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/new-account-creation-with-a-passkey 再掲
295. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 296 # パスキー深掘り - UX • ConditionalUI （w3c/webauthn Wiki · GitHubから引用） ◦ ID識別子/パスワードの入力フォームがあるログイン画面で パスワードマネージャーを利用したパスワード認証するUXと同 様のUXで認証するUX • ワンボタンクリック （独自定義） ◦ 既存のログイン画面にパスキー認証を発火させるボタンを設置 してボタンクリック（＋生体認証など）で認証するUX ＊他にもありますが抜粋してご紹介しています 参考元：「パスキーを使用したサインイン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/required-patterns/sign-in-with-a-passkey 「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI 再掲
296. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 297 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
297. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 298 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲
298. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 299 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel 再掲
299. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 300 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください 再掲
300. © OpenID Foundation Japan EOP 301