デジタルアイデンティティ技術 認可・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パッケージ製品の 導入、保守、運用をおこなっています。 最近はOIDC4IDAとPasskeyに興味があります。 宍戸優希（株式会社オプティム） 端末一括管理のサービス(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スキームを使った攻撃シナリオ 3/3 25 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 印刷アプリと同じカスタム URIスキームを設定した悪意のあるアプリは、 印刷アプリ →認可サーバへの認可リク エストの応答から認可コードを横取できる （※）。 ①アプリに権限を与えてもいいですよ 印刷アプリ ユーザー 写真アプリ 認可サーバ (スマホOS) スマホ 悪意のある アプリ ②認可コードを渡します 認可コード 印刷アプリと同じカスタ ムURIスキーマを設定 したので、認可コードを 横取りできた 認可リクエストに対するユーザーから の同意を得たので、 redirect_uri に設 定された print-app://oauth2redirect に認可コードを返却しよう カスタム URIスキーム 　print-app://oauth2redirect （※）認可コードを悪意のあるアプリが横取するための条件は、アプリがインストールされた端末の OSによって異なる。 ✖ 正規のアプリは認可コード を取得できなかった
26. ▪カスタムURIスキームとは 特定のネイティブアプリを起動するための特別なURI。 アプリケーション間通信や特定のアクションをトリガーするため に使う。 「https」というTLS通信用のURIスキームではなく、アプリ固有の文字列（例: myapp）を URIスキームとして利用することで、myappアプリを起動できる。 カスタムURIスキームを使った攻撃シナリオ 1/3 26 1.2. 認可コードを横取り攻撃とは：認可コード横取り攻撃の具体例 カスタムURIスキーム パラメータ付きのアプリ上の画面パス 【例】 myapp://open?screen=callback
27. カスタムURIスキームを使った攻撃シナリオ 2/3 27 ▪認可コード横取攻撃が成立する条件 • 正当なアプリはカスタム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
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実装者のための詳細説明：シーケンス解説 OPは、認可リクエストに設定されたリダイレクト URI が正当なものかどうかを確認できないので、認可 コードは悪意のあるアプリに横取されうる PKCE無しの場合、認可コードの送信元のアプリの 正当性を OPが検証することができないので 、アク セストークンが悪意のあるアプリに横取りされうる
33. 認可コード横取り攻撃含む認可リクエスト 33 ・攻撃者は、認可コードとstateを横取りすることで、 正規のユーザーに成りすましてトークンをリクエスト できます。 ・PKCEは横取りされた認可コードが不正に使われる のを防ぐ仕組みです。 ・RPでは、code_verifierとcode_challengeを生成し ます ・そのため、トークン発行時にcode_verifierと code_challengeの一致を確認することで、正規の ユーザーからのリクエストのみが許可され、横取りさ れた認可コードの悪用を防ぎます。 1.3. RP実装者のための詳細説明：シーケンス解説
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 の sub としてメールアドレスを連携する
52. メールアドレスをユーザー識別子とする、とは 3/3 52 メールアドレスをユーザー識別子として使用するリスク 良い例：ID Token の sub としてユーザー ID (例: UUID) を連携する
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. 適切なもの • ランダムに生成された識別子 (例: UUID) • 一意かつ、変化せず、再割り当てされない値であるもの 不適切なもの • メールアドレス • ID 基盤上の内部 id (例: 自動採番された数値) RP に連携するユーザー識別子として何が適切か 59 メールアドレスをユーザー識別子として使用するリスク
60. OpenID Provider 側 • ID Token の sub (= ユーザー識別子) にメールアドレスを用いない • 一意かつ、変化せず、再割り当てされないような値を用いる Relying Party 側 • ID Token, UserInfo で得たメールアドレスをユーザー識別子として扱わない • ここで得られるメールアドレスは、あくまで属性情報であることに注意 実装者の立場で意識すべきこと 60 メールアドレスをユーザー識別子として使用するリスク
61. 進んだ補足 : PPID について 1/2 61 メールアドレスをユーザー識別子として使用するリスク 複数の RP に同じ識別子を連携すると、RP 間で紐付け (名寄せ) が行えてしまう
62. 進んだ補足 : PPID について 2/2 62 メールアドレスをユーザー識別子として使用するリスク RP ごとに異なる識別子を割り当てて、紐付けができないようにする
63. メールアドレスをユーザー識別子として扱う場合のリスク • メールアドレスの所有者が別の人になっている可能性がある • メールアドレスの所有者が確認されていない可能性がある • OP 側でメールアドレスが変更されたことを RP 側で検知できない • RP 側にメールアドレスを隠すことができない OpenID Connect の実装者の観点で気をつけること • OP は ID Token の sub (= ユーザー識別子) にメールアドレスを用いない • RP は ID Token, UserInfo で得たメールアドレスをユーザー識別子として扱わない • ユーザー識別子には一意かつ、変化せず、再割り当てされない値を用いる まとめ 63 メールアドレスをユーザー識別子として使用するリスク
64. メールアドレスの所有者の確認 64 メールアドレスをユーザー識別子として使用するリスク メールを受信できるユーザーしか登録できないようにする
65. アクセストークンの検証と取り扱い 65
66. • OAuth 2.0 でのアクセストークン発行 & 利用の流れの振り返り • アクセストークンの種類 • アクセストークンの種類に応じた、情報を得る手段 • 権限判定に必要な情報 目次 66 アクセストークンの検証と取り扱い
67. どうやって特定のアクセスだけを許可するか？ 1/5 67 アクセストークンの検証と取り扱い クライアントは認可サーバーにアクセスしたいリソースを表明する
68. どうやって特定のアクセスだけを許可するか？ 2/5 68 アクセストークンの検証と取り扱い ユーザーを認証して「誰が」リソースへのアクセスを許可するのか特定する
69. どうやって特定のアクセスだけを許可するか？ 3/5 69 アクセストークンの検証と取り扱い ユーザーにアクセスへの同意を求める
70. どうやって特定のアクセスだけを許可するか？ 4/5 70 アクセストークンの検証と取り扱い ユーザーがアクセスに同意したことを表すトークンをクライアントに渡す
71. どうやって特定のアクセスだけを許可するか？ 5/5 71 アクセストークンの検証と取り扱い クライアントが正規のアクセストークンを持っていることを検証
72. どうやって特定のアクセスだけを許可するか？ 5/5 72 アクセストークンの検証と取り扱い クライアントが正規のアクセストークンを持っていることを検証 リソースサーバーがアクセストークンによる権限範囲を知る方法は？
73. Handle (または Artifact) • トークンは認可サーバー上のデータに対する参照のキーとなる役割 • トークンそのものには情報を含まず、データの参照と合わせて利用する Assertion • トークンの内部に情報を含める • 有効期間と発行対象の情報を持つことが多い • 改竄防止および発行者認証のために電子署名が付けられることが多い トークンの形式の種類 73 アクセストークンの検証と取り扱い ここでの「トークン」は アクセストークンに限らず リフレッシュトークンや認可コードも含む
74. Handle: アクセストークンが単なるキーである場合 • リソースサーバーが認可サーバーのデータに直接アクセスできない場合 ◦ 認可サーバーに問い合わせる ◦ アクセストークンそのものは、認可情報を取得するための識別子でしかない ◦ アクセストークンを認可サーバーに送り、レスポンスとして認可情報を受け取る ◦ パフォーマンスやスケーラビリティの点で不利 ◦ 参考仕様: RFC 7662 - OAuth 2.0 Token Introspection • リソースサーバーが認可サーバーのデータに直接アクセスできる場合 ◦ アクセストークンを用いて DB を直接参照し、情報を取得する ◦ リソースサーバーと認可サーバーが同一である場合、パフォーマンス等の懸念が小さい アクセストークンの形式に応じた情報取得の手段 1/6 74 アクセストークンの検証と取り扱い
75. アクセストークンの形式に応じた情報取得の手段 2/6 75 アクセストークンの検証と取り扱い Handle でリソースサーバーが認可サーバーのデータに直接アクセスできない場合
76. アクセストークンの形式に応じた情報取得の手段 3/6 76 アクセストークンの検証と取り扱い Handle でリソースサーバーが認可サーバーのデータに直接アクセスできる場合
77. Assertion: アクセストークン自体が情報を持っている場合 • アクセストークンの中に情報を入れ込む ◦ アクセストークンを JSON にするなどして、データを内部に含める ◦ 改竄を防ぐために署名が必要 ◦ Handle の場合と比較して失効させるのが大変 ◦ データを含められる (JSON) + 署名が入れられる (JWS) ため、JWT がよく利用される ◦ JWT 以外にも暗号化・署名付きの独自フォーマットのケースもある ◦ 参考仕様: RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens アクセストークンの形式に応じた情報取得の手段 4/6 77 アクセストークンの検証と取り扱い
78. アクセストークンの形式に応じた情報取得の手段 5/6 78 アクセストークンの検証と取り扱い Assertion の場合は認可サーバーとのやりとりなく権限判定が可能
79. Handle: アクセストークンが単なるキーである場合 • 認可サーバーとリソースサーバーが通信できない場合は使えない • ケースによって、パフォーマンスやスケーラビリティの観点で不利 Assertion: アクセストークン自体が情報を持っている場合 • Handle の場合と比較して失効させるのが大変 • クライアントに読まれる可能性があるので、含める情報に注意 アクセストークンの形式に応じた情報取得の手段 6/6 79 アクセストークンの検証と取り扱い
80. scope • 意味：クライアントがどのリソースへのアクセスを許可されたか? • 何を検証するか：要求されたリソースへの操作と scope の紐付き • 検証しない場合：アクセスを許可していないリソースへの操作が行われる subject • 意味：どのリソースオーナーの同意に基づいて発行されたか • 何を検証するか：要求されたリソースと subject の紐付き • 検証しない場合：アクセスを許可していないリソースへの操作が行われる アクセストークンを受け入れる際に検証すべき情報 1/3 80 アクセストークンの検証と取り扱い
81. issuer • 意味：どの認可サーバーにより発行されたか • 何を検証するか：アクセストークンを要求した先と一致するか • 検証しない場合：偽造されたアクセストークンを受け入れてしまう audience • 意味：どのリソースサーバーが受け取ることを想定して発行されたか • 何を検証するか：リソースサーバー自身の識別子を含むか • 検証しない場合：異なる用途のトークンを受け入れてしまう アクセストークンを受け入れる際に検証すべき情報 2/3 81 アクセストークンの検証と取り扱い
82. 有効期限 • 意味：アクセストークンの有効期限がいつまでか • 何を検証するか：有効期限が切れていないか • 検証しない場合：アクセス許可を取り消した後でも操作が行われる この他にも発行日時 (iat) や有効になる日時 (nbf) などあるが、省略 Assertion の場合には、改竄されたトークンを受け入れないよう署名検証も必要 アクセストークンを受け入れる際に検証すべき情報 3/3 82 アクセストークンの検証と取り扱い
83. アクセストークンの形式 • Handle (または Artifact)：権限情報を参照するキーの役割のみを果たす • Assertion：トークンそのものに権限情報を内包する アクセストークンの検証 • 権限判定には scope, subject, issuer など多様な情報が必要 • これらそれぞれを適切に検証しないと、様々なリスクが発生する まとめ 83 アクセストークンの検証と取り扱い
84. © OpenID Foundation Japan 登壇者紹介（認可・ ID連携担当） 84 米田良平 事業会社においてコンシューマ向けの認証認可基盤の構築を 担当しております。 私自身、ID/OIDCについて初心者ですので、みなさまと一緒に 学んで、OIDCに限らずIDの利用環境をよりよくすることに貢献 していきたいと思います。
85. OIDCにおけるCSRF 85
86. CSRFとは 86 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)
87. OpenID Connect（OIDC）とCSRF 87 OIDCはOAuth2.0をベースとした仕組みである。 OAuth2.0にはCSRFの脆弱性が存在するためCSRF攻撃を受けるリスクがある。 そのため、OIDCにおいても同様の脆弱性が存在することになる。 具体的には、リダイレクトURIに対してCSRF攻撃が行われる可能性がある。この攻撃で は、攻撃者のアカウントに紐づくリソースの操作権限が付与されたアクセストークンを利 用者に利用させ、攻撃者のリソースに利用者の情報を書き込ませることができ、攻撃者 は自身のアカウントにアクセスして利用者の情報を盗みとることが可能となる。 OAuth2.0の認可コードフローでCSRFの攻撃のメカニズムと対策を解説する。 1.1. CSRFとは
88. 利用者には知らず知らずのうちに攻撃者の権限が付与され、以下のような被害が発生 する。 被害例） 1. driveサービスの場合、攻撃者のdriveへ利用者のファイルがアップロードされてしま う。 2. 金融系サービスの場合、攻撃者のアカウントに利用者のクレカや口座情報が登録 されてしまう。 3. ECサイトの場合、攻撃者のアカウントに利用者などの送付先住所等が紐づけられ てしまう。 4. ポイント移行サイトの場合、攻撃者のアカウントに利用者のポイントが移行されてし まう。 この脆弱性による具体的な被害とは 88 1.1. CSRFとは
89. 以下のように認可コードフローは実行される。 認可コードフローの復習 89 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ①リソースオーナーが処理開始 ②クライアントが認可リクエストを実施 ③認可サーバーはログイン画面を返却 ④利用者がクレデンシャル入力 ⑤認可サーバーは同意画面を返却 ⑥利用者が同意する ⑦認可サーバーが認可コードを返却 ⑧クライアントが⑦で受け取った認可コードでア クセストークンリクエスト ⑨認可サーバーがアクセストークン /IDトークン返 却 ⑩アクセストークンでユーザー情報取得要求 ⑪リソースサーバーは clames返却 ⑫Clientでログイン処理を実施しログイン完了 ⑨ ⑩ ⑪ ⑫
90. 認可コードは認証/認可を行ったリソースオーナーのものとして発行される。 仮に、認可コードを盗み取って他人が利用すると、盗み取られた人のリソースにアクセス できてしまうことになる。CSRFはこの点も突く脆弱性と言える。 認可コードとリソースオーナー 90 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ 認証認可を行ったリソースオーナーものとして、 認可コードが発行される。
91. 攻撃者は事前準備として、攻撃者自身のアカウントで認証認可を済ませ認可コードを取 得する。 攻撃者による事前準備 91 1.2. CSRFの解説 リソースオーナー （被害者） ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ①攻撃者 が処理開始 ②クライアントが認可要求を実施 ③認証認可サーバーはログイン画面を返却 ④攻撃者 がクレデンシャル入力 ⑤認可サーバーは同意画面を返却 ⑥攻撃者 が同意する ⑦認可サーバーが 攻撃者へ 認可コードを返却 ⑦攻撃者に紐づく認可コードを取得する リソースオーナー （攻撃者）
92. 攻撃者は利用者に悪意あるURIを送付しクリックさせ、利用者に対して攻撃者のアカウ ント操作権限を付与させる。 利用者をだます 92 1.2. CSRFの解説 リソースオーナー （被害者） クライアント 認可サーバー リソースサーバー ① リソースオーナー （攻撃者） ユーザーエージェント ⑦́攻撃者が利用者へ何らかの手段で利用者に対して⑦で 受け取った認可コードを含むリダイレクトURIを送る ⑦́́利用者がURIをクリックする ⑧クライアントが⑦で受け取った認可コードでアクセストーク ンリクエスト ⑨認可サーバーがアクセストークン/IDトークン返却 ⑩アクセストークンでユーザー情報取得要求 ⑪リソースサーバーはclames返却 ⑫Clientでログイン処理を実施し攻撃者のアカウントとしてロ グイン完了 ⑦́悪意あるURIを送付 ⑦́́悪意あるURIをクリック ⑧ 攻撃者が取得した認可コードでアク セストークンリクエストが実行される ⑨攻撃者に紐づく アクセストークンが 返却される ⑩ ⑪攻撃者のリソース情 報が返却される
93. 利用者には知らず知らずのうちに攻撃者の権限が付与され、以下のような被害が発生 する。 被害例） 1. driveサービスの場合、攻撃者のdriveへ利用者のファイルがアップロードされてしま う。 2. 金融系サービスの場合、攻撃者のアカウントに利用者のクレカや口座情報が登録 されてしまう。 3. ECサイトの場合、攻撃者のアカウントに利用者などの送付先住所等が紐づけられ てしまう。 4. ポイント移行サイトの場合、攻撃者のアカウントに利用者のポイントが移行されてし まう。 この脆弱性による具体的な被害とは（再掲） 93 1.1. CSRFとは
94. フロー上の②から⑧のセッションが同一であることの保証がないから。 なぜCSRFが発生するのか？ 94 1.2. CSRFの解説 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ① ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ①利用者が処理開始 ②Back-End Serverが認可リクエストを実施 ③認証認可サーバーはログイン画面を返却 ④利用者がクレデンシャル入力 ⑤認証認可サーバーは同意画面を返却 ⑥利用者が同意する ⑦認証認可サーバーが認可コードを返却 ⑧Back-End Serverが⑦で受け取った認可コー ドでアクセストークンリクエスト ⑨認証認可サーバーがアクセストークン /IDトー クン返却 ⑩アクセストークンでユーザー情報取得要求 ⑪Userinfoはclames返却 ⑫Clientでログイン処理を実施しログイン完了 ⑨ ⑩ ⑪ ⑫ このセッションが同一であることの保 証がない
95. OAuth2.0（RFC6749）において、クライアントは自身のリダイレクトURIに対してCSRF 保護対策をすることを義務づけている。OAuth2.0ではその対策としてstateを利用を推 奨しており、stateを利用することがCSRF攻撃への対策となる。 stateは推測不能な値である必要がある。具体的な推測可能性は1/2^(-128)以下でなけ ればならず、1/2^(-160)以下であればなおよいとされている。 stateによる対策 95 1.3. CSRF対策
96. クライアントにて認可リクエスト時にstateを付与し、認可コード受取時のstateと比較を行 うことで、セッションの同一性が担保され、CSRF対策として有効。 stateの検証はクライアント、即ち、RPが行う点も対策のポイント。 stateによる対策 96 1.3. CSRF対策 リソースオーナー ユーザーエージェント クライアント 認可サーバー リソースサーバー ② state=αβγ　 ⑦ state=αβγ stateを認可serverへ送 信する ②で受け取った stateを 認可コードを返却する stateを生成しセッション に紐づけ クライアントでセッションに紐づ いたstateと受け取ったstateの 検証を実施 stateが一致することで、セッションの 同一性がほしょうされる。
97. • OIDCにはCSRF攻撃を受けるリスクがある。 • CSRF攻撃への対策にはstateの利用が有効。 • 認可サーバー（OIDCではIdP）、クライアント（OIDCではRP）が協力して対策を行う 必要がある。 • stateについては、クライアント（RP）で検証することで、有効に機能することを踏ま えて、クライアントは実装する必要がある。 CSRFまとめ 97 1.4. まとめ
98. stateと同等の役割を果たすパラメータとしてPKCEとnanceがある。それぞれについて概説しす る。 【PKCE】 OAuth2.0には認可コードを横取りされるリスクがあり、その対策として RFC7636で定義された PKCE（ピクシーと読む）を利用する事が望ましい。OIDCにおいても同様である。 【nonce】 OIDCではリプレイアタック対策としてnonce（ナンスと読む）が定義されている。 いずれのパラメータも、目的は違うものの同一セッションを保証するためのパラメーターとして機 能するため、次ページ以降でシーケンスを用いて解説する。 PKCEとnonce 98 1.5.Appendix
99. PKCEを利用することで、認可Server側でどの認可リクエストに対して発行した認可コー ドか判別できるため、横取りされた認可コードを利用することはできない。（詳細は 「PKCE概要」を参照） PKCEの概要 99 1.5.Appendix リソースオーナー ユーザーエージェント クライアント 認可Server リソースサーバー ② code_challenge=αβγ　 ⑧code_verifier =abc クライアントは改めて PKCEを送信する を認可serverへ送信す る code_verifierを code_challengeに変換し ②の値と比較検証 認可serverはPKCEと認可 コードを対で保持する
100. nonce（詳細はspecを参照）を利用することで、クライアント側でIDトークンの再利用を検 知することができ、リプレイアタックが成立しない。 nonceの概要 100 1.3. CSRF対策 リソースオーナー ユーザーエージェント クライアント 認可Server リソースサーバー 受け取ったnonceと②の nonceを比較検証する nonceを認可serverへ 送信する ②のnonceをID特に含 めて返却する ⑨ nonce=αβγ ② nonce=αβγ　
101. IDPはいずれのパラメータも利用できるようサービス提供することになる。 一方でRPもパラメータの意味を理解したうえで必要な処理を実装し、利用者を不正から 保護しなければならない。 stateとPKCEとnonceのまとめ 101 1.3. CSRF対策 パラメータ 防げる脆弱性 実装の主体者 ポイント state CSRF RP RP側で認可リクエストと認可コード受領 時点のセッション同一性保証ができる。 PKCE 認可コード横取り IDP IDP側で認可リクエストとアクセストーク ンリクエストのセッション同一性保証がで きる。 nonce リプレイアタック RP RP側で認可リクエストと IDトークン受領 時点のセッション同一性保証ができる。
102. © OpenID Foundation Japan 登壇者紹介 102 高城 勝信（株式会社ブリスコラ） APIフルライフサイクル管理をシームレスに行うプラットフォーム BAMsを開発しており、分散型の認証・認可標準の 知見も重要と考え、参画しました。 認証関連技術もたくさんあり、整理の大変さを身に染みて 感じております💦 持田さん、みなさまお疲れさまです ❗ 糸井佑磨（株式会社オプティム） IT×農業のシステム開発をしております。 私自身ID初学者ですが分かりやすく噛み砕いた説明になるよ う考えました。 認証担当
103. 7つの認証タイプ 103
104. 104 • このパートを取り上げた背景 ◦ 当人認証の強度について知ることで、普及期にあるパスキーの特性への理 解を深めるため • アウトラインの構成背景・概要 ◦ 2要素認証でもフィッシングにより当人認証が破られる事例がある ◦ フィッシング耐性がありUXも良いパスキーが当人認証の方法として普及期 にある ◦ AAL、認証機タイプ、toB, toCの事例をフィッシング耐性有無を中心に整理 する セクション
105. 背景・概要 105 • フィッシング耐性有無を中心にAAL、認証機タイプ、toB, toCの事例 を整理する。 • より実践的な内容を多く扱いたいため、AAL、認証機タイプについて は概説にとどめ、toB, toCの事例を厚めに説明する。 セクション
106. 2. 参考文献 106 NIST SP 800-63-4※ 米国政府機関システムの技術要件をまとめるNISTが 提供するデジタル認証に関する包括的なガイドライン。 （※ 基礎編では2024年6月19日当時最新版だったInitial-Public-Draft を引用していたが、2024年8月21日に2nd-Public-Draftが発行されたた め、応用編では主に2PDを引用している。本資料で参照しているのは Finalではないことに留意。） 7つの認証器タイプ - 2. 参考文献
107. アウトライン 107 1. 認証の定義を復習 2. AALの説明 3. 7つの認証器について概要説明 4. フィッシング耐性がない認証器の説明 5. フィッシング耐性がある認証器の説明 6. toBでのAALの適用事例説明 7. toCでのAALの適用事例説明 セクション
108. 1. 認証の定義を復習 108 基礎編のP.101を引用して「認証の定義」を復習 セクション
109. 1. 認証の定義を復習 109 基礎編のP.103を引用して「認証器の妥当性を判断する」ことという復習 セクション
110. 2. AALの説明 110 「800-64-4-2pd」「3.3.1. Assurance Levels」でAALの概要説明 セクション
111. 2. AALの説明 111 「800-64-4-2pd」「3.3.2.2. Authentication Assurance Level」で3段階 の説明 セクション
112. 3. 7つの認証器について概要説明 112 高城さんと、糸井がまとめたスプレッドシートからカラムをピックアップ セクション
113. 4. フィッシング耐性がない認証器の説明 113 1. パスワード 2. ルックアップシークレット 3. アウトオブバンドデバイス 4. 単一要素OTP 5. 多要素OTP 上記について、 1. 認証方法を概略図で説明 2. スプレッドシートから事例・認証要素・AAL・メリット・デメリットをピックアップ セクション
114. 5. フィッシング耐性がある認証器の説明 114 1. 単一要素暗号認証 2. 多要素暗号認証 上記について、 1. 認証方法を概略図で説明 2. スプレッドシートから事例・認証要素・AAL・メリット・デメリットをピック アップ セクション
115. 6. toBでのAAL適用事例 115 • FIDOのセミナーで事例紹介がいくつかあったので拝借したい • 破られた事例も含めるか？ セクション
116. 7. toCでのAAL適用事例 116 • FIDOのセミナーで事例紹介がいくつかあったので拝借したい • 破られた事例も含めるか？ セクション
117. 目次 117 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ
118. 目次 118 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 1. 背景・概要
119. 1. 背景・概要 119 • 2要素認証でもフィッシングにより当人認証 (Authentication)が破られる事例があり、昨今は フィッシング情報の届出件数も増えている。 • 当人認証の保証レベル(Authentication Assurance Level、以下、AAL)や認証器タイプ (Authenticator Type)について知ることで、フィッシング耐性があり、普及期にあるパスキーへ の理解を深める足掛かりとする。 7つの認証器タイプ - 1. 背景・概要 引用：「フィッシング対策協議会 / フィッシングレポート 2023」https://www.antiphishing.jp/report/phishing_report_2023.pdf
120. 目次 120 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 2. 参考文献
121. 2. 参考文献 • 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ではないことに留意 121 7つの認証器タイプ - 2. 参考文献 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
122. 2. 参考文献 122 • フィッシング対策協議会 ◦ フィッシングレポート 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つの認証器タイプ - 2. 参考文献
123. 2. 参考文献 123 • 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つの認証器タイプ - 2. 参考文献
124. 2. 参考文献 124 • 内閣サイバーセキュリティセンター ◦ 重要インフラ対策関連 ▪ 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つの認証器タイプ - 2. 参考文献
125. 2. 参考文献 125 • 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つの認証器タイプ - 2. 参考文献
126. 2. 参考文献 126 • 経済産業省 ◦ 工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン 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つの認証器タイプ - 2. 参考文献
127. 2. 参考文献 127 • 総務省 ◦ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 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つの認証器タイプ - 2. 参考文献
128. 2. 参考文献 128 • 株式会社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つの認証器タイプ - 2. 参考文献
129. 目次 129 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 3. 認証の定義
130. 3. 認証の定義 130 Authentication (当人認証)には強度という概念が存在する。 例えば、読書記録アプリに比べて金融系アプリでは、当人認証が侵害された際の 金銭的損失の影響度が大きく、より高い強度が求められる。 AuthenticationにはAuthenticator Type (認証器タイプ)という分類があり、それぞれ で強度 ≒ Authentication Assurance Level (AAL: 当人認証保証レベル)が定義さ れている。 Authenticator Typeの分類にあたって、Authenticationの定義を本セクションで、 AALの定義を次セクションで理解する。 7つの認証器タイプ - 3. 認証の定義
131. 3. 認証の定義 131 Digital Authenticationとは、 デジタルアイデンティティの確らしさを確立するプロセス。 7つの認証器タイプ - 3. 認証の定義 # 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
132. 3. 認証の定義 132 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
133. 3. 認証の定義 133 Authenticatorとは、 ClaimantのIdentityをAuthenticationする際、所有および管理を証明さ れるもの。 7つの認証器タイプ - 3. 認証の定義 # 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
134. 3. 認証の定義 134 Authenticator Typeとは、 共通の特徴を持つAuthenticatorの分類。 7つの認証器タイプ - 3. 認証の定義 # 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
135. 3. 認証の定義 135 Authentication Factorとは、 something you know, something you have, something you areを指 す。 7つの認証器タイプ - 3. 認証の定義 # 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
136. 目次 136 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 4. AALの定義
137. 4. AALの定義 137 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つの認証器タイプ - 4. AALの定義 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
138. 4. AALの定義 138 DIRM Processとは、 オンラインサービスを受けたい人が受けられるようになっていることを 大前提として、 損害と影響を評価し、 保証レベルを選択・カスタマイズして、 継続的に評価・改善を行うこと。 AALは、 「Step3」で選択され、「Step4」でカスタマイズされる。 7つの認証器タイプ - 4. AALの定義 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Step1: オンラインサービスを定義する Step2: ユーザー層毎に初期影響評価を 実施する Step3: ユーザー層毎に初期保証レベルと ベースラインコントロールを選択する Step4:ユーザー層毎に保証レベルを カスタマイズして文書化する オンラインサービスのための ID管理システムを、導入 /調整する Step5:継続的に評価し改善する
139. 4. AALの定義 139 AAL(Authentication Assurance Level)とは、 Authenticationプロセス自体、およびAuthenticatorと個人の紐付けの 堅牢性。 7つの認証器タイプ - 4. 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
140. 4. AALの定義 140 AAL1とは、 基本レベルの信頼性を提供する。1要素認証のみが要求される。 7つの認証器タイプ - 4. 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
141. 4. AALの定義 141 AAL2とは、 高い信頼性を提供する。2つの異なるAuthentication Factorを所有・管理して いる証明が必要とされる。フィッシング耐性のある認証オプションが提供されな ければならない。 7つの認証器タイプ - 4. 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
142. 4. AALの定義 142 AAL3とは、 非常に高い信頼性を提供する。2つの異なるAuthentication Factorを所有・管理している証明が必要とさ れる。エクスポート不可能な秘密鍵を持つハードウェアベースのAuthenticatorと、フィッシング耐性のある Authenticatorが必要である。 7つの認証器タイプ - 4. 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
143. 4. AALの定義 143 以上の定義から、オンラインサービスに必要な保証レベルを制御目的に応じて選択 ・カスタマイズすることが重要である 7つの認証器タイプ - 4. 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侵害への保護を提供する
144. 目次 144 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 5. 7つの認証器
145. 5. 7つの認証器 145 NIST SP 800-63B では DIRM Process に沿って、AALを元にAuthenticator Type を整理している。 しかし、高い信頼性を提供するAAL2に分類されるAuthenticator Typeであっても、 フィッシングによりAuthenticationが破られる事例がある。 そのため、以降ではAALも参照しつつ、大枠ではフィッシング耐性有無によって Authenticator Typeを概説する。 Authenticator Typeによっては各AALを満たすための追加要件もあるが、ここでは 各Authenticator Typeの典型的な使用例に絞って概説する。 7つの認証器タイプ - 5. ７つの認証器
146. 5. 7つの認証器 146 7つの認証器タイプ - 5. ７つの認証器 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
147. 目次 147 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 5. 7つの認証器
148. 5-1. フィッシング耐性が ない認証器の説明 148 パスワード 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Subjectが発行
149. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ 実装が簡単でユーザーも理解しやすい ◦ 特別なハードウェアが不要 • デメリット ◦ 弱いパスワードや再利用されたパスワードは破られやすい ◦ フィッシング攻撃やブルートフォース攻撃に弱い 149 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
150. 5-1. フィッシング耐性が ない認証器の説明 150 ルックアップシークレット 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e CSPが発行
151. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ ユーザーが覚える必要がない情報を利用できる ◦ 物理的なアイテムや生体情報を利用することで、セキュリティを強化できる • デメリット ◦ 秘密の質問は予測可能な回答が多く、セキュリティが低い場合がある ◦ 生体認証デバイスや特殊なカードが必要な場合、コストがかかる 151 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
152. 5-1. フィッシング耐性が ない認証器の説明 152 アウトオブバンドデバイス(PrimaryDeviceにシークレットを転送する場合) 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Verifierが発行し、 SecondaryDeviceに表示させ、 PrimaryDeviceで入力
153. 5-1. フィッシング耐性が ない認証器の説明 153 アウトオブバンドデバイス(Out-of-band Deviceにシークレットを転送する場合) 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e Verifierが発行し、 PrimaryDeviceに表示させ、 SecondaryDeviceで入力
154. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ 主要な通信チャネルとは別の手段を使用するため、セキュリティが強化される ◦ ユーザー体験が向上し、利便性が高い • デメリット ◦ SMSやメールは中間者攻撃に弱いことがある ◦ 通信障害があると認証ができない場合がある 154 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
155. 5-1. フィッシング耐性が ない認証器の説明 155 単一要素OTP 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e OTP Device or Softwareが発行し、 PrimaryChannelで入力
156. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1 • メリット ◦ パスワードよりも安全な一度きりのパスワードを提供できる ◦ ユーザーが持ち運び可能である • デメリット ◦ デバイスを紛失した場合、アクセスができなくなる ◦ デバイスが必要なため、コストがかかる 156 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
157. 5-1. フィッシング耐性が ない認証器の説明 157 多要素OTP 7つの認証器タイプ - 5. ７つの認証器 引用：「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を行う
158. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1, AAL2 • メリット ◦ 単一要素よりもセキュリティが強化される ◦ パスワードとデバイスの組み合わせが不正アクセスを防ぐ • デメリット ◦ デバイスを紛失するとアクセスが困難になる ◦ 初期設定や管理が複雑になることがある 158 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
159. 5-1. フィッシング耐性が ない認証器の説明 159 単一要素暗号認証 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e パスワードは秘密鍵の暗号化に 使用され、認証要素ではない。 公開鍵暗号方式であり、 something you haveの単要素認証となる。
160. 5-1. フィッシング耐性が ない認証器の説明 160 • Channel Binding、Verifier Name Bindingを満たす場合のみフィッシング耐性あり。 • AAL ◦ AAL1 • メリット ◦ パスワード管理が容易になる。 ◦ 自動ログイン機能で利便性が向上する。 ◦ 物理的なデバイスを使用するため、セキュリティが強化される。 • デメリット ◦ ソフトウェアの脆弱性が攻撃の対象になる。 ◦ マルウェアによる攻撃リスクがある。 ◦ デバイスを紛失した場合、アクセスができなくなる。 ◦ コストがかかる。 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
161. 5-1. フィッシング耐性が ない認証器の説明 • Channel Binding、Verifier Name Bindingを満たす場合のみフィッシング耐性あり • AAL ◦ AAL1, AAL2 • メリット ◦ ユーザーは 1つの情報を覚えておけばよく、使用が簡単 ◦ 様々なシステムで広く使用されており、ユーザーにも馴染み深い • デメリット ◦ 単一の認証要素が侵害されると不正アクセスが可能になるためセキュリティが比較的低い ◦ 暗号技術の正確な実装と管理が必要で、実装が複雑 161 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
162. 目次 162 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 5. 7つの認証器
163. 5-2. フィッシング耐性が ある認証器の説明 163 多要素暗号認証 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e パスワードも認証要素として使用する。 秘密鍵の暗号化には別の仕組みを使用する。 公開鍵暗号方式と組み合わせるため、多要素認証となる
164. 5-2. フィッシング耐性が ある認証器の説明 164 多要素暗号認証 • AAL ◦ AAL1, AAL2, AAL3 • メリット ◦ TODO • デメリット ◦ TODO 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
165. 5-1. フィッシング耐性が ない認証器の説明 • AAL ◦ AAL1, AAL2, AAL3 • メリット ◦ 複数の認証要素を組み合わせることで不正アクセスのリスクを大幅に低減できる • デメリット ◦ 初期設定が複雑で一部のユーザーにとっては障壁になることがある 165 7つの認証器タイプ - 5. ７つの認証器 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
166. 目次 166 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 6. toB, toCでの事例
167. 6. toB, toCでの事例 167 ここまで、フィッシング耐性有無やAALを元にAuthenticator Typeを整理してきた。 上記を踏まえ、toB, toCでの各ガイドラインを参照し推奨される認証方式の事例紹介と 整理を行う。 7つの認証器タイプ - 6. toB, toCでの事例 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
168. 7. toBでの事例 168 事例1(2要素認証が必須ではないサービス掻き集め) • 決済が絡むサービス ◦ OPTiM Store、bplats • 重要な情報を扱うサービス ◦ OPTiM Contract、Optimal Biz、楽楽精算、KDDI SMARTアドレス帳 セクション 引用：「OPTiM Store」https://www.optim.co.jp/store/ 「Optimal Biz」https://www.optimalbiz.jp/ 「OPTiM Contract」https://www.optim.co.jp/optim-contract/ 「楽楽精算」https://www.rakurakuseisan.jp/ 「KDDI SMARTアドレス帳」https://biz.kddi.com/service/smart-address/ 「bplats」https://www.bplats.co.jp/product_bplats/
169. 7. toBでの事例 169 事例2(2要素認証が必須なサービス掻き集め) • Azure・Microsoft365、 セクション 引用：「Azure やその他の管理ポータルに必須の多要素認証の計画」 https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-mandatory-multifactor-authentication
170. 7. toBでの事例 170 事例3(PCI-DSS) • (メモ: MFAガイド(PCI-DSSのv3に対応)がアーカイブ状態。 ◦ PCI-DSSのv4に対応するMFAガイドは2025年に公開予定 ◦ v4ではMFA必須とは書かれていない ◦ v3ではMFA必須と書かれている セクション 引用：「PCI-DSS-v4.0-JA」https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4_0-JA.pdf 「PCI-SSC / Multi-Factor Authentication Guidance V1」 https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Authentication/Multi-Factor-Authentication-Guidance-v1.pdf 7つの認証器による分類表
171. 7. toBでの事例 171 マップ • 切り口案 ◦ 業界(IT・流通・サービス業・医療・金融・不動産・建設・製造 ) ◦ SaaSのサービス区分(人事労務系・企画営業支援系・ソースコード管理系、など ) ◦ ユーザー層(人事・労務・経理・営業・企画・技術職・経営層・管理職・一般社員、など ) セクション 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e
172. 8. toCでの事例 172 事例1(パスワードだけのサービス掻き集め) • 決済が絡むサービス ◦ ヨドバシドットコム(ゴールドポイントカード)、KFC、ピザーラ、スシロー • 重要な個人情報が絡むサービス ◦ GeneLife セクション 引用：「GeneLife」https://customer.genelife.jp/sign_up 「GeneLife STORE」https://genelife.jp/ec/user_data/guide.php 「ヨドバシ・ドット・コムの会員登録」https://www.yodobashi.com/ec/support/member/entry/index.html 「ゴールドポイントカードプラス /はじめてメンバーズページをご利用の会員様へ」https://www.goldpoint.co.jp/registration/index.html 「KFC /会員登録方法をおしえてください。」https://faq.order.kfc.jp/faq/show/1604?site_domain=kfcj_faq 「ピザーラ / 会員登録して注文する」https://www.pizza-la.co.jp/contents/html/regist.html 「少年ジャンプ+ / ヘルプ/使い方」https://shonenjumpplus.com/article/help 「ユニクロ /会員登録について」https://faq.uniqlo.com/articles/FAQ/100001981 「スシロー / 1. 会員登録/ログイン時の注意事項」https://www.akindo-sushiro.co.jp/appsv2/other/faq.html 「スシロー / よくあるご質問」https://takeout.akindo-sushiro.co.jp/faq
173. 8. toCでの事例 173 事例2 dアカウントでは、基本的にパスワード + SMSで認証している。 (アプリによる認証も可能 ) ドコモオンラインショップでは、一部での購入手続きをパスキー必須としている。 (ドコモ版デジタルアイデンティティガイドラインを策定しており、 dAALを運用している。) セクション 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e 「ドコモ回線契約があるお客さま / 新たなdアカウントの作成」 https://id.smt.docomo.ne.jp/src/appli/create_account.html 「ドコモ回線契約がないお客さま / 新たなdアカウントの作成」 https://id.smt.docomo.ne.jp/src/appli/create_account2.html 「購入手続き時の認証について」 https://onlineshop.smt.docomo.ne.jp/supports/purchase_info.html 「日本銀行決済機構局 ISOパネル（第7回） / 説明資料（生体認証技術の活用と展望）」 https://www.boj.or.jp/paym/iso/iso_panel/data/isop230307e.pdf サービス 認証 認証器 フィッシング耐性 AAL 備考 dアカウント パスワード + SMS での2要素認証 パスワード: パスワード SMS: アウトオブバンドデバイス なし AAL2 ユーザー層のリテラシーが多様であると予想されることから、 フィッシング耐性はないが、ユーザビリティを損なわない程度の認証強度として、 パスワード + SMS での2要素認証にしていると考えられる。 ドコモ オンラインショップ (一部) パスキー 多要素暗号 あり AAL3 ユーザー層がリテラシーが高いと予想されること、 認証が侵害された際の経済的損失が大きいと予想されることから、 フィッシング耐性のある多要素暗号を必須にしていると考えられる。
174. 8. toCでの事例 174 事例3 メルカリ(フリマアプリ)では、パスワード + SMSで認証している。 メルコイン(ビットコイン取引)では、パスキーでの認証を必須としている。 セクション 引用：「NIST Special Publication 800-63-4-2PD」https://github.com/usnistgov/800-63-4/tree/f3cf4a159edbc4402bd88f56de31a027f3708f2e 「【初心者向け】メルカリの登録方法を解説！会員登録の 5ステップ」https://jp-news.mercari.com/contents/1556 「メルカリ / ヘルプセンター」 https://help.jp.mercari.com/guide/articles/1103/ サービス 認証 認証器 フィッシング耐性 AAL 備考 メルカリ パスワード + SMS での2要素認証 パスワード: パスワード SMS: アウトオブバンドデバイス なし AAL2 ユーザー層のリテラシーが多様であると予想されることから、 フィッシング耐性はないが、ユーザビリティを損なわない程度の認証強度として、 パスワード + SMS での2要素認証にしていると考えられる。 メルコイン パスキー 多要素暗号 あり AAL3 ユーザー層がリテラシーが高いと予想されること、 認証が侵害された際の経済的損失が大きいと予想されることから、 フィッシング耐性のある多要素暗号を必須にしていると考えられる。
175. 目次 175 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 6. toB, toCでの事例
176. 6-1. toBでの事例 176 大分類 ガイドライン 交通・物流分野 ・航空分野における情報セキュリティ確保に係る安全ガイドライン ・空港分野における情報セキュリティ確保に係る安全ガイドライン ・鉄道分野における情報セキュリティ確保に係る安全ガイドライン ・物流分野（貨物自動車運送）における情報セキュリティ確保に係る安全ガイドライン ・物流分野（倉庫）における情報セキュリティ確保に係る安全ガイドライン ・物流分野（船舶運航）における情報セキュリティ確保に係る安全ガイドライン ・港湾分野における情報セキュリティ確保に係る安全ガイドライン 製造分野 ・工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン ・ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド ・制御システムのセキュリティリスク分析ガイド ・建設現場ネットワークの構築と運用ガイドライン 医療分野 ・医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン ・医療情報システムの安全管理に関するガイドライン 商取引・決済分野 ・PCI-DSS ・ECサイト構築・運用セキュリティガイドライン 働き方関連 ・テレワークセキュリティガイドライン 7つの認証器タイプ - 6. toB, toCでの事例
177. 6-1. toBでの事例 - (商取引・決済分野 ) 177 7つの認証器タイプ - 6. toB, toCでの事例 • 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
178. 6-1. toBでの事例 178 • 経済産業省 ◦ 工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 (2022年11月16 日) ▪ 【3.2 ステップ2 セキュリティ対策の立案】 • 高強度のセキュリティが要求される場合には、多要素認証による対策が例示されてい る • 中強度のセキュリティが要求される場合には、単要素認証による対策が例示されてい る 7つの認証器タイプ - 6. toB, toCでの事例
179. 6-1. toBでの事例 179 • IPA ◦ ECサイト構築・運用セキュリティガイドライン (2023年3月16日) ▪ 【第2部 1. EC サイトの構築時及び運用時における講じるべきセキュリティ対策要件】 • 管理者画面や管理用ソフトへの接続は端末を制限した上で多要素認証を行うことが必須とされている ◦ ビル設備におけるサイバーセキュリティセルフチェックシート設問項目ガイド (2023年7月) ▪ 【2.5. 「運用」段階】 • リモートアクセスでの不正アクセス防止の対策として多要素認証が例示されている • 所持情報としてFIDOセキュリティキーが例示されている ◦ 制御システムのセキュリティリスク分析ガイド第2版 (2023年3月) ▪ 【B.4.1. 制御システムの境界防御チェックシート】 • リモートアクセスする全てのユーザは、トークンベース認証等の強力な認証を要求されることが望ましい とされている • 認証の例として、単純なパスワード、複雑なパスワード、多要素認証、トークン、生体認証、スマートカー ド等が例示されている 7つの認証器タイプ - 6. toB, toCでの事例
180. 6-1. toBでの事例 - (交通・物流分野 ) 180 7つの認証器タイプ - 6. toB, toCでの事例 • 国土交通省 ◦ 航空分野における情報セキュリティ確保に係る安全ガイドライン第 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
181. 6-1. toBでの事例 - (製造分野) 181 7つの認証器タイプ - 6. toB, toCでの事例 • 経済産業省 ◦ 工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 (2022年11月16日) ▪ 【3.2 ステップ2 セキュリティ対策の立案】 • 高強度のセキュリティが要求される場合には、多要素認証による対策が例示されている • 中強度のセキュリティが要求される場合には、単要素認証による対策が例示されている 引用：「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver1.0 」 https://www.meti.go.jp/policy/netsecurity/wg1/factorysystems_guideline_ver1.0.pdf
182. 6-1. toBでの事例 - (製造分野) 182 7つの認証器タイプ - 6. toB, toCでの事例 • 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
183. 6-1. toBでの事例 - (製造分野) 183 7つの認証器タイプ - 6. toB, toCでの事例 • 一般社団法人日本建設業連合会 ◦ 建設現場ネットワークの構築と運用ガイドライン (2024年2月) ▪ 【 6.4. 利用デバイスと情報漏洩対策】 • 管理者によるシステムのアクセスにおいては、 IP制限や端末制限をかけることが望ましいとされてい る。 • どちらもできない場合は、多要素認証が情報漏洩対策の強化方法として例示されている • 個人アカウントの乗っ取りやパスワード流出対策として、多要素認証が例示されている 引用：「建設現場ネットワークの構築と運用ガイドライン」 https://www.nikkenren.com/publication/fl.php?fi=1416&f=202404_nwglcs.pdf
184. 6-1. toBでの事例 - (医療分野) 184 7つの認証器タイプ - 6. toB, toCでの事例 • 総務省・厚生労働省 ◦ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 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
185. 6-1. toBでの事例 - (商取引・決済分野 ) 185 7つの認証器タイプ - 6. toB, toCでの事例 • 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
186. 6-1. toBでの事例 - (働き方関連 ) 186 7つの認証器タイプ - 6. toB, toCでの事例 • 総務省 ◦ テレワークセキュリティガイドライン第 5版 (2021年5月) ▪ 【第4章 2. システム・セキュリティ管理者が実施すべき対策】 • システム管理者においては、可能な限り多要素認証を強制することが対策として例示されている 引用：「テレワークセキュリティガイドライン第 5版」 https://www.soumu.go.jp/main_content/000752925.pdf
187. 6-1. toBでの事例 - (まとめ) 187 7つの認証器タイプ - 6. toB, toCでの事例 • 多要素認証を行う際の 認証器タイプの組み合わせ例、事例は大まかに以下のように整理できる 大分類 認証器タイプ組み合わせ例 事例 交通・物流分野 ・多要素OTP (パスワード + 単一要素OTP) ・多要素暗号 (パスワード + 単一要素暗号) ・PINコードを要求するセキュリティトークン ・Google Authenticator ・YubiKey 製造分野 ・多要素OTP (パスワード + 単一要素OTP) ・多要素暗号(パスワード + 単一要素暗号) ・パスワード + 手のひら静脈認証 ・Google Authenticator ・YubiKey 医療分野 ・パスワード + ルックアップシークレット ・PIN + 指紋認証 商取引・決済分野 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・パスワード + 秘密の質問 ・PIN + SMSによるOTP 働き方関連 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・PIN + 秘密の質問 ・パスワード + メールへのマジックリンク送信
188. 6-1. toBでの事例 - (まとめ) 188 7つの認証器タイプ - 6. toB, toCでの事例 • 内閣サイバーセキュリティセンターによって重要インフラ分野として特定されている分野において はほとんどの場合、多要素認証が必要とされている。 • 重要インフラ以外の分野においても、乗っ取りや成りすましの対策として多要素認証が例示され ている。 • NIST-SP-800-63-4-2PD においては多要素認証に分類される認証強度の中でもさらにフィッシン グ耐性の有無について言及していること、参照したガイドライン群の多くは NISTの文書を参考に 作成されていることから、国内のガイドライン群でもフィッシング耐性のある多要素認証に対する 記述が追加されていくと予想される。すでに、重要インフラ分野においてはフィッシング耐性のな い多要素認証が非推奨とされている場合もある。現在は AAL2相当の記述が多いが、 AAL3相当 の記述が追加されていくと予想される。
189. 目次 189 1. 背景・概要 2. 参考文献 3. 認証の定義 4. AALの定義 5. 7つの認証器 5-1. フィッシング耐性がない認証器 5-2. フィッシング耐性がある認証器 6. toB, toCでの事例 6-1. toBでの事例 6-2. toCでの事例 7つの認証器タイプ - 6. toBでの事例
190. 6-2. toCでの事例 190 大分類 ガイドライン・サービス 高額決済サービス ・ドコモオンラインショップ ・メルコイン 商取引・決済分野 ・ECサイト構築・運用セキュリティガイドライン ・利用者向けフィッシング詐欺対策ガイドライン ・クレジットカード・セキュリティガイドライン ・メルカリ 医療分野 ・医療情報システムの安全管理に関するガイドライン 7つの認証器タイプ - 6. toB, toCでの事例
191. 6-2. toCでの事例 - (高額決済サービス ) 191 7つの認証器タイプ - 6. toB, toCでの事例 • 株式会社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/
192. 6-2. toCでの事例 - (商取引・決済分野 ) 192 7つの認証器タイプ - 6. toB, toCでの事例 • 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
193. 6-2. toCでの事例 - (商取引・決済分野 ) 193 7つの認証器タイプ - 6. toB, toCでの事例 • 一般社団法人日本クレジット協会 ◦ クレジットカード・セキュリティガイドライン 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
194. 6-2. toCでの事例 - (医療分野) 194 7つの認証器タイプ - 6. toB, toCでの事例 • 厚生労働省 ◦ 医療情報システムの安全管理に関するガイドライン第 6.0版 (2023年5月) ▪ 【7.2.2 患者等に診療情報等を提供する場合の外部からのアクセス】 • 患者等に診療情報等を提供したり参照閲覧させたりする場合においても、職員による外部アクセス と同等の対策を講じることが求められている • つまり、2027年度時点で稼働が想定される医療情報システムでは、患者によるアクセスでも多要素 認証が必要となる 引用：「医療情報システムの安全管理に関するガイドライン第 6.0版(システム運用編) 」 https://www.mhlw.go.jp/content/10808000/001112044.pdf
195. 6-2. toCでの事例 - (まとめ) 195 7つの認証器タイプ - 6. toB, toCでの事例 • 多要素認証を行う際の 認証器タイプの組み合わせ例、事例は大まかに以下のように整理できる 大分類 認証器タイプ組み合わせ例 事例 高額決済サービス ・多要素暗号 (パスワード + 単一要素暗号) ・YubiKey ・Google Titan Security Key ・PassKey 商取引・決済分野 ・パスワード + ルックアップシークレット ・パスワード + アウトオブバンドデバイス ・多要素OTP (パスワード + 単一要素OTP) ・パスワード + 秘密の質問 ・パスワード + SMSによるOTP ・Google Authenticator 医療分野 ・パスワード + ルックアップシークレット ・PIN + 指紋認証
196. 6-2. toCでの事例 - (まとめ) 196 7つの認証器タイプ - 6. toB, toCでの事例 • 幅広いユーザー層へのサービス提供を鑑み、多要素認証を必須にするまでは至っていない が、積極的に推奨はされている。 • 一部ではユーザー層と金銭的損失を鑑み、フィッシング耐性のある多要素認証の導入を必 須としているサービスも出てきており、これは AAL3に相当する。 • 金銭的損失の影響度が大きいサービス、医療情報など機密性が求められるサービスについ てはAAL3に相当するフィッシング耐性のある多要素認証が積極的に導入されていくと予想 される。
197. © OpenID Foundation Japan 登壇者紹介 197 持田 捷宏（LINEヤフー株式会社） これからIDを学びたい方でもわかるよう ミスリードがないように資料を作成しました IDに興味を持って正しく学ぶきっかけになれば幸いです 認証担当
198. © OpenID Foundation Japan パスキー深掘り 198
199. © OpenID Foundation Japan 参考文献 出典元を明確にして 後日詳細を確認できるようにする 199
200. © OpenID Foundation Japan 参考文献と注意事項 200 # パスキー深掘り - 参考文献 参考文献 FIDOアライアンス W3C 注記 詳細を確認する際には一次情報をご参照ください
201. © OpenID Foundation Japan はじめに 201 # パスキー深掘り • このセクションでは以下の定義で用語を扱います ◦ ID：デジタルアイデンティティ ◦ ログイン：認証+サービスを継続利用できるための処理 • 用語についての詳細な説明は実装パートで実施します • 本日はまとめた資料の一部をピックアップして発表します。全貌につ きましては公開される資料をご確認ください。
202. © OpenID Foundation Japan UX 【目的】 パスキーを導入する上で どういったUXが提供できるのか 理解する 【聞き手】 パスキーの導入を検討している 開発者 202
203. © OpenID Foundation Japan デザインガイドライン | Passkey Central 203 # パスキー深掘り - UX ◼パスキー・セントラル FIDOアライアンスにより作成され パスキーの導入や運用に関する情報が集約されている ◼デザインガイドライン 調査により策定したパスキーに関するUXについて紹介されている 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
204. © OpenID Foundation Japan パスキー作成の UXパターン 204 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
205. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 205 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
206. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 206 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 認証器に渡すI/F パスキー作成要求に対する 成果物 ＊Attestationについては 次のスライドで説明します パスキー作成に必要な情報
207. © OpenID Foundation Japan アテステーションとアサーション 207 # パスキー深掘り - 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 認証器が作成する秘密鍵で署名されたオブジェクト パスキー認証時に生成される
208. © OpenID Foundation Japan これまでの認証の UX 208 # パスキー深掘り - UX ログイン画面上に ID識別子/パスワードの入力フォームがあり ID識別子/パスワードを入力して ログインボタンをクリックするUX ＊パスワードマネージャーを利用する場合 　Autofillで認証するUXになる サンプルサービス ログイン メールアドレス ログイン パスワード
209. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 209 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com
210. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 210 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com パスキー認証導入後 ユーザーにパスキー認証を利用してもらうためにも 親しみのある UXの中でパスキー認証を提供する 工夫が必要になる
211. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 211 # パスキー深掘り - 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
212. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 212 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
213. © OpenID Foundation Japan ConditionalUI（シーケンス図） 213 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する パスキー認証に必要な情報 認証器に渡すI/F パスキー認証要求に対する 成果物
214. © OpenID Foundation Japan 【目的】 UXのセッションで説明したUXを 提供するための実装を理解する インターフェースの説明にフォーカスし ています 具体的な処理について触れません 実装 214
215. © OpenID Foundation Japan ブラウザ↔認証器↔ユーザーの I/F 215 # パスキー深掘り - 実装 ◼パスキー作成 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
216. © OpenID Foundation Japan PublicKeyCredentialCreationOptions（全体像） 216 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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
217. © OpenID Foundation Japan rp - フィッシング耐性がある理由 217 # パスキー深掘り - 実装 - パスキー作成 - 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を使用すること はできない。 →フィッシング耐性がある
218. © OpenID Foundation Japan authenticatorSelection - パスキー作成時に必要な項目 218 # パスキー深掘り - 実装 - パスキー作成 - 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
219. © OpenID Foundation Japan PublicKeyCredentialRequestOptions（全体像） 219 # パスキー深掘り - 実装 - パスキー認証 参考元：「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 認証器に依頼する追加の処理
220. © OpenID Foundation Japan ConditionalUIを提供に必要な項目 220 # パスキー深掘り - 実装 - パスキー認証 ◼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
221. © OpenID Foundation Japan ConditionalUIを提供するための実装 221 ◼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
222. © OpenID Foundation Japan まとめ パスキー深掘り 222
223. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 223 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
224. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 224 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
225. © OpenID Foundation Japan 以降、資料の全貌になります。 225
226. © OpenID Foundation Japan UX 【目的】 パスキーを導入する上で どういったUXが提供できるのか 理解する 【聞き手】 パスキーの導入を検討している 開発者 226
227. © OpenID Foundation Japan UX パスキー作成 227 セッションの構成 • ID管理画面で作成 ◦ UIイメージ ◦ シーケンス図 • 訴求画面で作成 ◦ UIイメージ ◦ シーケンス図 • 新規ID作成と同時に作成 ◦ UIイメージ ◦ シーケンス図
228. © OpenID Foundation Japan デザインガイドライン | Passkey Central 228 # パスキー深掘り - UX ◼パスキー・セントラル FIDOアライアンスにより作成され パスキーの導入や運用に関する情報が集約されている ◼デザインガイドライン 調査により策定したパスキーに関するUXについて紹介されている 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
229. © OpenID Foundation Japan パスキー作成の UXパターン 229 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
230. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 230 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings
231. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 231 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 認証器に渡すI/F パスキー作成要求に対する 成果物 ＊Attestationについては 次のスライドで説明します パスキー作成に必要な情報
232. © OpenID Foundation Japan アテステーションとアサーション 232 # パスキー深掘り - 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 認証器が作成する秘密鍵で署名されたオブジェクト パスキー認証時に生成される
233. © OpenID Foundation Japan パスキー作成の UXパターン 233 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
234. © OpenID Foundation Japan 既存の認証方法で認証後パスキーを作成する 訴求画面でパスキー作成 （UIイメージ） 234 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 ログイン user@example.com サンプルサービス ログイン メールアドレス サンプルサービス サンプルサービス パスキー作成完了 ******** パスワード パスキー パスキーの説明 … … … パスキー作成 あとで サンプルサービス パスキー パスキーの説明 … … … パスキー作成 あとで パスキーを 作成しますか？ 次へ パスキー管理画面 OK 参考元：「SMS OTPを廃止する | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/deprecate-sms-otp
235. © OpenID Foundation Japan 訴求画面でパスキー作成 （シーケンス図） 235 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存の認証方法で認証後パスキーを作成する
236. © OpenID Foundation Japan パスキー作成の UXパターン 236 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/
237. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （UIイメージ） 237 # パスキー深掘り - 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
238. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （シーケンス図） 238 # パスキー深掘り - UX - パスキー作成の UXパターン - 新規IDに対するパスキー作成 ユーザーにID識別子を入力してもらいパスキーを作成する
239. © OpenID Foundation Japan セッションの構成 • パスワード認証 • ConditionalUI ◦ UIイメージ ◦ シーケンス図 • ワンボタンクリック ◦ UIイメージ ◦ シーケンス図 UX パスキー認証 239
240. © OpenID Foundation Japan これまでの認証の UX 240 # パスキー深掘り - UX ログイン画面上に ID識別子/パスワードの入力フォームがあり ID識別子/パスワードを入力して ログインボタンをクリックするUX ＊パスワードマネージャーを利用する場合 　Autofillで認証するUXになる サンプルサービス ログイン メールアドレス ログイン パスワード
241. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 241 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com
242. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 242 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード パスワードからパスキーへの移行 前 user@example.com パスキー認証導入後 ユーザーにパスキー認証を利用してもらうためにも 親しみのある UXの中でパスキー認証を提供する 工夫が必要になる
243. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 243 # パスキー深掘り - 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
244. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 244 # パスキー深掘り - 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 なぜ登場したのか
245. © OpenID Foundation Japan WebAuthnの認証のプライバシー 245 # パスキー深掘り - 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で判断できない
246. © OpenID Foundation Japan パスキーを利用する際の同意 246 # パスキー深掘り - 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
247. © OpenID Foundation Japan ConditionalUIの背景 247 # パスキー深掘り - UX - パスキー認証の UXパターン - ConditionalUIの背景 WebAuthnで定義されているプライバシーの関係上RPは 「パスキーを利用できるかもしれないのでパスキー認証を発火させてみ る」という対応しかできない パスキーを利用できない場合ユーザーに混乱を招きうる体験になってし まう課題感があった 参考元：「Explainer: WebAuthn Conditional UI · w3c/webauthn Wiki · GitHub」https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI パスキーを利用できればパスキーを利用する パスキーを利用できなければ別の認証方法を利用する 認証のUXを提供することで解決している
248. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 248 # パスキー深掘り - 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 再掲
249. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 249 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
250. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 250 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間
251. © OpenID Foundation Japan ConditionalUI（シーケンス図） 251 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する パスキー認証に必要な情報 認証器に渡すI/F パスキー認証要求に対する 成果物
252. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 252 # パスキー深掘り - 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
253. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 253 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
254. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 254 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel
255. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 255 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください
256. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 256 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください パスワードを扱わないログイン画面 パスワードを扱わないのでログイン画面から ID識別子/パスワードの入力フォームがなくなり ユーザーがフィッシングサイトに ID識別子/パスワードを入力してしまうリスクが なくなる
257. © OpenID Foundation Japan ボタンクリック（＋生体認証）で認証するUX ワンボタンクリック（シーケンス図） 257 # パスキー深掘り - UX - パスキー認証の UXパターン
258. © OpenID Foundation Japan 【目的】 UXのセッションで説明したUXを 提供するための実装を理解する インターフェースの説明にフォーカスし ています 具体的な処理について触れません 実装 258
259. © OpenID Foundation Japan ブラウザ↔認証器↔ユーザーの I/F 259 # パスキー深掘り - 実装 ◼パスキー作成 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
260. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 260 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 再掲
261. © OpenID Foundation Japan ConditionalUI（シーケンス図） 261 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する 再掲
262. © OpenID Foundation Japan 実装 セッションの構成 • ID管理画面で作成 ◦ UIイメージ ◦ シーケンス図 ▪ I/Fの説明 • 訴求画面で作成 ◦ 差分なし • 新規ID作成と同時に作成 ◦ 差分なし パスキー作成 262
263. © OpenID Foundation Japan パスキー作成の UXパターン 263 # パスキー深掘り - UX 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/ 再掲 • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊これから説明する実装がどの UXについての説 明になるのか UXを振り返ります
264. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 264 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings 再掲
265. © OpenID Foundation Japan ID管理画面でパスキー作成 （シーケンス図） 265 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する 再掲 ＊四角で囲まれた I/Fについて説明していきます
266. © OpenID Foundation Japan パラメータの詳細説明 266 # パスキー深掘り - 実装 • RPで保存が推奨される PublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成されるPublicKeyCredentialの詳細
267. © OpenID Foundation Japan RPで保存が推奨される PublicKeyCredentialの情報 267 # パスキー深掘り - 実装 パスキー作成時に作成される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 それぞれの項目が なぜ必要なのか 以降のスライドで説明します
268. © OpenID Foundation Japan パラメータの詳細説明 268 # パスキー深掘り - 実装 • RPで保存が推奨されるPublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成されるPublicKeyCredentialの詳細
269. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 269 # パスキー深掘り - 実装 - パスキー作成 ブラウザを介して認証器に対して 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
270. © OpenID Foundation Japan PublicKeyCredentialCreationOptions（全体像） 270 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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
271. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 271 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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で参照される項目
272. © OpenID Foundation Japan rp - フィッシング耐性がある理由 272 # パスキー深掘り - 実装 - パスキー作成 - 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を使用すること はできない。 →フィッシング耐性がある
273. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 273 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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で参照される項目
274. © OpenID Foundation Japan user - ConditionalUIで参照される項目 274 # パスキー深掘り - 実装 - パスキー作成 - 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の値が優先して表示される
275. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 275 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲 ↑ここに表示される ユーザー名として user.nameが使用される
276. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 276 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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で参照される項目
277. © OpenID Foundation Japan ランダムに生成されたArrayBuffer。 推測されないよう少なくとも16バイトである必要がある。 challenge - リプレイ攻撃耐性がある理由 277 # パスキー深掘り - 実装 - パスキー作成 - 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
278. © OpenID Foundation Japan PublicKeyCredentialCreationOptions 278 # パスキー深掘り - 実装 - パスキー作成 項目 必須 指定する情報 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で参照される項目
279. © OpenID Foundation Japan authenticatorSelection - パスキー作成時に必要な項目 279 # パスキー深掘り - 実装 - パスキー作成 - 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
280. © OpenID Foundation Japan パラメータの詳細説明 280 # パスキー深掘り - 実装 • RPで保存が推奨されるPublicKeyCredentialの情報 • PublicKeyCredentialCreationOptionsの詳細 ◦ navigator.credentials.createに渡すoptions • 作成される PublicKeyCredentialの詳細
281. © OpenID Foundation Japan PublicKeyCredential（全体像） 281 # パスキー深掘り - 実装 - パスキー作成 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。
282. © OpenID Foundation Japan PublicKeyCredential - id 282 # パスキー深掘り - 実装 - パスキー作成 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で参照される項目
283. © OpenID Foundation Japan PublicKeyCredential - isConditionalMediationAvailable() 283 # パスキー深掘り - 実装 - パスキー作成 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なインターフェース
284. © OpenID Foundation Japan PublicKeyCredential - response 284 # パスキー深掘り - 実装 - パスキー作成 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。 次のスライド以降で詳しく説明していきます
285. © OpenID Foundation Japan response - パスキー作成時（全体像） 285 # パスキー深掘り - 実装 - パスキー作成 - 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の情報 が格納される項目に絞り説明します
286. © OpenID Foundation Japan パスキー作成時に生成される PublicKeyCredential の response に含まれる attestationObject の項目で Authenticator Data と Attestation Statement が含まれる CBOR*エンコードされたオブジェクト。 *CTAP2で定義されているCompact Binary Object Representation attestationObject 286 # パスキー深掘り - 実装 - パスキー作成 - 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
287. © OpenID Foundation Japan Authenticator Data - rpIdHash 287 # パスキー深掘り - 実装 - パスキー作成 - 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でもフィッシング検知可能な仕様になっている
288. © OpenID Foundation Japan Authenticator Data - signCount 288 # パスキー深掘り - 実装 - パスキー作成 - 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はリスク判定に利用することができる
289. © OpenID Foundation Japan Authenticator Data - flags 289 # パスキー深掘り - 実装 - パスキー作成 - 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に指定した処理の結果が格納される。 次のスライド以降で説明していきます
290. © OpenID Foundation Japan Authenticator Data - flags 290 # パスキー深掘り - 実装 - パスキー作成 - 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
291. © OpenID Foundation Japan Authenticator Data - flags 291 # パスキー深掘り - 実装 - パスキー作成 - 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のビジネス要件を満たす振る舞いを選択できる
292. © OpenID Foundation Japan attestedCredentialData - 公開鍵が格納される 292 # パスキー深掘り - 実装 - パスキー作成 - 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
293. © OpenID Foundation Japan transports 293 # パスキー深掘り - 実装 - パスキー作成 - 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が どの方法で利用可能なのかを 認証器に伝えるために利用する
294. © OpenID Foundation Japan 実装 セッションの構成 • ConditionalUI ◦ UIイメージ ◦ シーケンス図 ▪ I/F説明 • ワンボタンクリック ◦ UIイメージ ◦ シーケンス図 ▪ I/F説明 パスキー認証 294
295. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 295 # パスキー深掘り - 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を振り返ります
296. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 296 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲
297. © OpenID Foundation Japan ConditionalUI（シーケンス図） 297 # パスキー深掘り - UX - パスキー認証の UXパターン AutofillのUXで認証する 再掲 ＊四角で囲まれた I/Fについて説明していきます
298. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 298 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel 再掲
299. © OpenID Foundation Japan ボタンクリック（＋生体認証）で認証するUX ワンボタンクリック（シーケンス図） 299 # パスキー深掘り - UX - パスキー認証の UXパターン 再掲 ＊四角で囲まれた I/Fについて 説明していきます
300. © OpenID Foundation Japan パラメータの詳細説明 300 # パスキー深掘り - 実装 • PublicKeyCredentialRequestOptionsの詳細 ◦ navigator.credentials.getに渡すoptions • 作成されるPublicKeyCredentialの詳細
301. © OpenID Foundation Japan PublicKeyCredentialRequestOptions 301 # パスキー深掘り - 実装 - パスキー認証 参考元：「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
302. © OpenID Foundation Japan PublicKeyCredentialRequestOptions（全体像） 302 # パスキー深掘り - 実装 - パスキー認証 参考元：「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 認証器に依頼する追加の処理
303. © OpenID Foundation Japan PublicKeyCredentialRequestOptions 303 # パスキー深掘り - 実装 - パスキー認証 参考元：「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で参照される項目
304. © OpenID Foundation Japan ConditionalUIを提供に必要な項目 304 # パスキー深掘り - 実装 - パスキー認証 ◼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
305. © OpenID Foundation Japan ConditionalUIを提供するための実装 305 ◼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
306. © OpenID Foundation Japan パラメータの詳細説明 306 # パスキー深掘り - 実装 • PublicKeyCredentialRequestOptionsの詳細 ◦ navigator.credentials.getに渡すoptions • 作成される PublicKeyCredentialの詳細
307. © OpenID Foundation Japan PublicKeyCredential（全体像） 307 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()のみ
308. © OpenID Foundation Japan response - 公開鍵暗号方式で署名される項目 308 # パスキー深掘り - 実装 - パスキー認証 - 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の改ざんの検知も可能
309. © OpenID Foundation Japan clientDataJSON - リプレイ攻撃耐性 309 # パスキー深掘り - 実装 - パスキー作成 - 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等が改ざんされても署名検証で検知できる仕組みになっている
310. © OpenID Foundation Japan まとめ パスキー深掘り 310
311. © OpenID Foundation Japan パスキー作成の UXパターン 311 # パスキー深掘り - UX • 既存IDに対するパスキー作成 ◦ ID管理画面で作成 ◦ 訴求画面で作成 • 新規IDに対するパスキー作成 ◦ 新規ID作成と同時に作成 ＊他にもありますが抜粋してご紹介しています 参考元：「デザインガイドライン | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/ 再掲
312. © OpenID Foundation Japan ID管理画面でパスキー作成 （UIイメージ） 312 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 既存IDの管理画面でパスキーを作成する サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 サンプルサービス セキュリティ パスキー パスキーの説明 … … … パスキー作成 パスキーを 作成しますか？ 次へ サンプルサービス セキュリティ パスキー作成完了 パスキー管理画面 ユーザー名 user メールアドレス 参考元：「アカウント設定でパスキーを作成・表示・管理する | Passkey Central」 https://www.passkeycentral.org/ja/design-guidelines/required-patterns/create-view-and-manage-passkeys-in-account-settings 再掲
313. © OpenID Foundation Japan 既存の認証方法で認証後パスキーを作成する 訴求画面でパスキー作成 （UIイメージ） 313 # パスキー深掘り - UX - パスキー作成の UXパターン - 既存IDに対するパスキー作成 ログイン user@example.com サンプルサービス ログイン メールアドレス サンプルサービス サンプルサービス パスキー作成完了 ******** パスワード パスキー パスキーの説明 … … … パスキー作成 あとで サンプルサービス パスキー パスキーの説明 … … … パスキー作成 あとで パスキーを 作成しますか？ 次へ パスキー管理画面 OK 参考元：「SMS OTPを廃止する | Passkey Central」https://www.passkeycentral.org/ja/design-guidelines/optional-patterns/deprecate-sms-otp 再掲
314. © OpenID Foundation Japan 新規ID作成と同時にパスキー作成 （UIイメージ） 314 # パスキー深掘り - 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 再掲
315. © OpenID Foundation Japan パスキーを利用した認証 （パスキー認証） のUXパターン 315 # パスキー深掘り - 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 再掲
316. © OpenID Foundation Japan ID識別子/パスワードの入力フォームがある画面でパスワード認証 パスワード認証 （UIイメージ） 316 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com パスワードからパスキーへの移行 前 再掲
317. © OpenID Foundation Japan 既存のログイン画面のままでパスワード認証のAutofillと同じUXでパス キー認証をするUX ConditionalUI （UIイメージ） 317 （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 ログイン サンプルサービス ログイン メールアドレス パスワード ログイン パスワード user@example.com メールアドレス ログイン ******** パスワード user@example.com 生体認証をしてください # パスキー深掘り - UX - パスキー認証の UXパターン パスワードからパスキーへの移行 期間 再掲
318. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 318 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン メールアドレス サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン メールアドレス ログイン パスワード パスキーでログイン 生体認証をしてください パスワードからパスキーへの移行 期間 パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel 再掲
319. © OpenID Foundation Japan ボタンクリック（＋生体認証など）で認証するUX ワンボタンクリック （UIイメージ） 319 # パスキー深掘り - UX - パスキー認証の UXパターン （サービスを提供する） サンプルサービス ログイン サンプルサービス ログイン サンプルサービス ログイン完了 サンプルサービス ログイン パスワードからパスキーへの移行 期間 パスキーでログイン パスキーでログイン パスキーを 使用しますか？ —-------------------------- user@example.com —-------------------------- … cancel パスキーでログイン 生体認証をしてください 再掲
320. © OpenID Foundation Japan EOP 320
321. 質疑応答 321
322. © OpenID Foundation Japan Appendix 322
323. タイトル 323 コンテンツ セクション
324. タイトル 324 絵や表 タイトル ＜要点（このスライドで伝えたいことや重要なポイントなど）＞