デジタルアイデンティティ技術 認可・ID連携・認証 基礎

Transcript

1. © OpenID Foundation Japan © OpenID Foundation Japan デジタルアイデンティティ技術 認可・ID連携・認証 基礎 一般社団法人 OpenID ファウンデーション・ジャパン デジタルアイデンティティ人材育成推進ワーキンググループ 技術サブワーキンググループ 2024年6月19日
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 登壇者紹介 認可・ID連携担当 4
5. © OpenID Foundation Japan 登壇者紹介（認可・ID連携担当） 5 松本 優大（ソフトバンク株式会社） ID 領域を学び始めたのは、入社してからでまだ初学者です が、一緒に学ぶみなさまとともに成長していきたいと思っていま す。 吉村 拓眞 （株式会社オプティム） 私自身が ID 初学者ですので、初学者なりの視点で、初学者 の方に伝わるよう説明を考えました。 同じくこれから ID を学ぶみなさま、一緒に頑張っていきましょ う！
6. © OpenID Foundation Japan 認可技術の基礎 6
7. © OpenID Foundation Japan 認可とは 7 認可技術の基礎 インターネットが普及した現代では、 webAPIが多用されている アプリケーションは、外部が提供している webAPIを使用して位置情報・動画を取得したり、 SNSへ投稿したりと いったことが可能である 例として、あるアプリケーションで 「SNSで投稿」することで、広告をスキップできるため、アプリケーションに投稿をする許可を与えた アプリケーションに SNSに投稿する許可を 与えますか？ 許可 許可しない
8. © OpenID Foundation Japan 認可とは 認可とは、システムやアプリケーションの特定の機能やリソースに対してアクセスするための権限を与えること 英語表記　：Authorization / AuthZ 8 認可技術の基礎 この時、ユーザはアプリケーションに対して、 SNSの投稿する権限のみを与えた 実装観点では、SNSがアプリケーションに対して、ユーザの ID/PWを連携することだが、 それでは、アプリケーションに対して、全権限を与えることになってしまう 個人情報（ID/PW）をやり取りし、アプリケーションが自由にアクセスできる状態は好ましいとは言えない できるのであれば、アプリケーションには、最低限の権限（今回でいえば、特定の投稿をする権限）のみを与え たいものである（認可） この認可を簡単に実現するためのフレームワークとして「 OAuth 2.0」がある
9. © OpenID Foundation Japan 2010年4月より、draft-ietf-oauth-v2として考えられ、2012年10月にRFC6749で正式に策定された ※認可のプロトコルとして、OAuth1.0(2007年〜)も存在する OAuth 2.0 概要　ー　策定までの略歴 9 認可技術の基礎 出典元：Datatracker (https://datatracker.ietf.org/doc/rfc6749/history/) draft-ietf-oauth-v2 RFC6749 2010/04 2012/10 2024/06
10. © OpenID Foundation Japan OAuth 2.0 概要　ー　実現できること 10 認可技術の基礎 OAuth2.0は 「サードパーティーアプリケーションによる HTTPサービスへの限定的なアクセスを可能にする認可フレームワー ク」 ▪OAuth2.0がないと リソースへのアクセスを必要としているサービスに対して、必要以上のアクセス権（フルアクセス権）を与えてし まう （アプリにID/PWを渡して代理ログインしてもらうしかない。。） ▪OAuth2.0があることで ユーザーは限られたアクセス権限をサービスに対して与えることができる 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
11. © OpenID Foundation Japan OAuth 2.0 概要　ー　実現できること ユーザーは、印刷サービスで Google Photos上にある写真を印刷をしたい。 印刷サービスはGoogle Photosにアクセスするために、ユーザーに許可を得て、 Google Photosにアクセスする 権限を与えられた。 ①Google Photosにアク セスする権限をください ②印刷サービスにアクセスする権限 を与えていいですか 11 認可技術の基礎 印刷サービス ユーザー Google Photos Google
12. © OpenID Foundation Japan OAuth 2.0 概要　ー　実現できること ④アクセス権を付与します ③印刷サービスに権限を与 えてもいいですよ アクセス権 ⑤Google Photosにアクセスする権限もらった ので、写真データください ⑥アクセス権あるんですね。 　どうぞ、データあげます アクセス権 写真データ ①〜④までのやり取りの仕様を OAuth2.0 アクセス権のことを「 Access Token」という 12 認可技術の基礎 印刷サービス ユーザー Google Photos Google 印刷サービス ユーザー Google Photos Google
13. © OpenID Foundation Japan OAuth 2.0 概要　ー　実現できること（OAuth2.0での登場人物） リソースオーナー / resource owner（ユーザー） 保護されたリソースへのアクセスを許可する存在 クライアント / client（印刷サービス） リソースオーナーの認可を得て , リソースオーナーの代理として保護されたリソースに対するリクエストを行うア プリケーション 認可サーバー / authorization server（Google） リソースオーナーの認証とリソースオーナーからの認可取得が成功した後 , アクセストークンをクライアントに発 行するサーバー リソースサーバー / resource server（Google Photos） 保護されたリソースをホストし , アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポン スを返すことのできるサーバー 13 認可技術の基礎 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
14. © OpenID Foundation Japan OAuth 2.0 各Grant Type解説 14
15. © OpenID Foundation Japan 4つのGrant Type 15 リソースオーナーによる認可を示し、クライアントがアクセストークンを取得するタイプが４つ定義されている OAuth 2.0 各Grant Type解説 Grant Type 概要 Authorization Code Grant 認可コードによりユーザーエージェントと経由せずにクライアントにアクセストークンを送信でき データの露出リスクを低減する。 Implicit Grant JavaScriptなどのブラウザー上のクライアントに最適化されている。 認可コードのように仲介するクレデンシャルがないため「Implicit=暗黙の」と呼ばれる。 クライアントが直接アクセストークンを受信するため、リソースオーナーやユーザーエージェント 経由で他のアプリケーションに晒される可能性がある。 Resource Owner Password Credentials Grant リソースオーナーのパスワードを直接送信してアクセストークンを取得する。 リソースオーナーとクライアントの間で高い信頼があり、他のGrant Typeが利用できない場合の み使用されるべきである。 Client Credentials Grant 認可範囲がクライアントの管理下にある保護されたリソース、もしくは認可サーバーとの間で調 整済みの保護されたリソースに制限されている場合に使用される。
16. © OpenID Foundation Japan Authorization Code Grant 16 認可コードグラントタイプは, アクセストークンとリフレッシュトークの両方を取得するために用 いられ, コンフィデンシャルクライアントに最適化されている. このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソース オーナーのユーザーエージェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダ イレクトを通した) リクエストを受け付けることが出来なくてはいけない. OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html) コンフィデンシャルクライアントとは クレデンシャルの機密性を維持することができるクライアント
17. © OpenID Foundation Japan Authorization Code Grant (A) クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで , フ ローが開始する . このときクライアントは , クライアント識別子 , リクエストスコープ , ローカルステー ト, および認可サーバーがアクセス許可 (あるいは拒否 ) 取得後にユーザーエージェントを戻すリ ダイレクトURIをリクエストに含める . (B) 認可サーバーは (ユーザーエージェント経由で ) リソースオーナーを認証し , リソースオーナー にアクセス要求の許可 /拒否をたずねる . (C) リソースオーナーがアクセスを許可した場合 , 認可サーバーは予め与えられていた (リクエスト もしくはクライアント登録時に指定される ) リダイレクトURIを用いて, ユーザーエージェントをリダイ レクトさせてクライアントに戻す . リダイレクトURIには, 認可コード, クライアントから事前に送られ たローカルステートが含まれる . (D) クライアントは前のステップで取得した認可コードを認可サーバーのトークンエンドポイントに 送ることでアクセストークンを要求する . このとき, クライアントは認可サーバーとの間で認証を行う . またクライアントは認可コード取得時に使用したリダイレクト URIを検証のためリクエストに含める . (E) 認可サーバーはクライアントを認証し , 認可コードを検証し , 受け取ったリダイレクト URIがス テップ (C) で使用したURIと同一であることを確かめる . その結果, 正当である場合 , 認可サー バーはアクセストークンと任意でリフレッシュトークンを返却する . 17 OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
18. © OpenID Foundation Japan Authorization Code Grant 18 (A)認可リクエスト (B)リソースオーナー認証・アクセス要求の許可/拒否 (C)リダイレクトURIで認可コードを付与 (D)トークンリクエストで認可コードを送信 (E)アクセストークン（任意でリフレッシュトークン）返却 アクセストークンでリソース取得 OAuth 2.0 各Grant Type解説
19. © OpenID Foundation Japan Authorization Code Grant 19 OAuth 2.0 各Grant Type解説 リソースオーナー クライアント 認可サーバー リソースサーバー ユーザーエージェント (A)認可リクエスト (B)リソースオーナー認証・アクセス要求の許可 /拒否 (C)リダイレクト URIで認可コードを付与 (E)アクセストークン（任意でリフレッシュトークン）返却 アクセストークンでリソース取得 (D)トークンリクエストで認可コードを送信
20. © OpenID Foundation Japan Implicit Grant 20 インプリシットグラントタイプは , アクセストークンを取得するために用いられ (リフレッシュトークンの発行はサポートさ れない), 特定のリダイレクトURIを利用することが既知であるパブリッククライアントに最適化されている . これらのクラ イアントは, 通常JavaScriptなどのスクリプト言語を使用してブラウザ上に実装される . このグラントタイプではリダイレクトベースのフローが利用されるため, クライアントはリソースオーナーのユーザーエー ジェント (通常はWebブラウザ) と対話し, 認可サーバーによる (リダイレクトを通した) リクエストを受け付けることが出 来なくてはいけない. 認可リクエストとアクセストークン取得のリクエストが分離されている認可コードグラントタイプと異なり , クライアントは 認可リクエストの結果としてアクセストークンを受け取る . インプリシットグラントタイプでは クライアント認証は行わず, リソースオーナーの介在とリダイレクト URIの事前登録に 頼っている. アクセストークンはリダイレクト URI中にエンコードされるため, リソースオーナーと同一デバイス上のその 他のアプリケーションに漏えいするかもしれない . OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
21. © OpenID Foundation Japan Implicit Grant (A) クライアントがリソースオーナーのユーザーエージェントを認可エンドポイントに送ることで , フ ローが開始する . このときクライアントは , クライアント識別子 , リクエストスコープ , ローカルステー ト, および認可サーバーがアクセス許可取得後にユーザーエージェントを戻すリダイレクト URIをリ クエストに含める . (B) 認可サーバーは (ユーザーエージェントを通して ) リソースオーナーを認証し , リソースオー ナーにアクセス要求の許可 /拒否をたずねる . (C) リソースオーナーがアクセスを許可した場合 , 認可サーバーは予め与えられていたリダイレク トURIを用いて, ユーザーエージェントをリダイレクトさせてクライアントに戻す . リダイレクトURIに は, アクセストークンが含まれる . (D) ユーザーエージェントは , リダイレクトの指示に従い , Web上にホストされたクライアントリソー スにリクエストを送信する (このときフラグメントは送信されない .[RFC2616]を参照). ユーザー エージェントはフラグメントの情報をローカルに保持する . (E) Webでホストされたクライアントリソースにアクセスすると , Webページ (通常, 埋め込みのスク リプトが含まれる HTMLドキュメント) が返される. そのWebページでは, ユーザーエージェントに よって保持されているフラグメントを含む完全なリダイレクト URLにアクセスし, フラグメントに含ま れているアクセストークン (とその他のパラメーター ) を取り出すことができる . (F) ユーザーエージェントは上記 Webページに含まれるスクリプトをローカルに実行し , アクセス トークンを取り出す . (G) ユーザーエージェントはアクセストークンをクライアントに渡す . 21 OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
22. © OpenID Foundation Japan Implicit Grant 22 (A)認可リクエスト (B)リソースオーナー認証・アクセス要求の許可/拒否 (C)リダイレクトURIでアクセストークン付与 (D)リダイレクトURI (E)スクリプトが含まれるHTMLを返却 (F)スクリプトでアクセストークンを抽出 (G)アクセストークンを付与 アクセストークンでリソース取得 OAuth 2.0 各Grant Type解説
23. © OpenID Foundation Japan Implicit Grant 23 OAuth 2.0 各Grant Type解説 リソースオーナー クライアント 認可サーバー リソースサーバー ユーザーエージェント Webホステッド クライアントリソース (A)認可リクエスト (B)リソースオーナー認証・アクセス要求の許可 /拒否 (C)リダイレクト URIでアクセストークン付与 (D)リダイレクト URI (E)スクリプトが含まれる HTMLを返却 (F)スクリプトでアクセストークンを抽出 (G)アクセストークンを付与 アクセストークンでリソース取得
24. © OpenID Foundation Japan Resource Owner Password Credentials Grant 24 リソースオーナーパスワードクレデンシャルグラントタイプは , リソースオーナーがクライアントと信頼 関係にある場合, 例えばリソースオーナーの所有するデバイス OSや特別許可されたアプリケーショ ンなどに適している. 認可サーバーはこのグラントタイプを有効にする際は特に注意するべきである . また他のフローが利 用できない場合にのみ許可するべき である. このグラントタイプは, リソースオーナーのクレデンシャル (通常は対話型入力フォームにて取得する ユーザー名とパスワード) を取得できるクライアントに適している . また, 保存済みのクレデンシャルをアクセストークンへ変換できるため , Basic認証やDigest認証のよ うな直接的な認証スキームを利用している既存のクライアントを OAuthへ移行する際にも利用できる. OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
25. © OpenID Foundation Japan Resource Owner Password Credentials Grant (A) リソースオーナーはクライアントにユーザー名とパスワードを提供する . (B) クライアントは認可サーバーのトークンエンドポイントにリソースオーナーから取得したクレデン シャルを含めることでアクセストークンを要求する . リクエストを生成する際に , クライアントは認可 サーバーによって認証される . (C) 認可サーバーはクライアントを認証し , リソースオーナーのクレデンシャルを検証する . もし有 効であればアクセストークンを発行する . 25 OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
26. © OpenID Foundation Japan Resource Owner Password Credentials Grant 26 (A)ユーザー名とパスワード（クレデンシャル）を提供 (B)トークンリクエストでクレデンシャルを送信（クライアント認証を要求） (C)クライアントを認証し、リソースオーナーのクレデンシャルを検証。そ れらが有効であればアクセストークンを発行 OAuth 2.0 各Grant Type解説
27. © OpenID Foundation Japan Resource Owner Password Credentials Grant 27 OAuth 2.0 各Grant Type解説 リソースオーナー クライアント 認可サーバー (A)ユーザー名とパスワード（クレデンシャル）を提供 (B)トークンリクエストでクレデンシャルを送信（クライアント認証を要求） (C)クライアントを認証し、リソースオーナーのクレデンシャルを検証。 それらが有効であればアクセストークンを発行
28. © OpenID Foundation Japan Client Credentials Grant 28 クライアント自身のコントロール下にある保護リソースまたは認可サーバーとの間で調整済みの保護 リソースにアクセスする場合, クライアントはクライアントクレデンシャル (あるいはサポートされている その他の認証方式) のみでアクセストークンをリクエストすることができる . コンフィデンシャルクライアントのみ が, クライアントクレデンシャルグラントタイプを利用できる (MUST). OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
29. © OpenID Foundation Japan Client Credentials Grant (A) クライアントは自身の認証情報を含めてトークンエンドポイントにアクセストークンリクエストを 送る. (B) 認可サーバーはクライアントを認証し , 認証に成功すればアクセストークンを発行する . 29 OAuth 2.0 各Grant Type解説 出典元：OAuth 2.0 Authorization Framework (https://openid-foundation-japan.github.io/rfc6749.ja.html)
30. © OpenID Foundation Japan Client Credentials Grant 30 (A)トークンリクエストでクライアント認証情報（クレデンシャル）を送信 (B)クライアントを認証し、成功すればアクセストークンを発行 OAuth 2.0 各Grant Type解説
31. © OpenID Foundation Japan Client Credentials Grant 31 OAuth 2.0 各Grant Type解説 クライアント 認可サーバー (A)トークンリクエストでクライアント認証情報（クレデンシャル）を送信 (B)クライアントを認証し、成功すればアクセストークンを発行
32. © OpenID Foundation Japan ID連携技術の基礎 32
33. © OpenID Foundation Japan ID連携とは 33 ID連携技術の基礎 ID連携とは、複数のシステムやサービスに対し、ユーザーの属性情報を提供すること ID連携はさまざまなサービスで触れる機会が多いと思いますが、以下の特徴 （一部）がある メリット ・複数のサービスでアカウントを作成しなくてもいいため、ユーザーの利便性向上 ・サービス立ち上げの際に、認証基盤の構築が不要のため、導入コスト削減・運用コスト削減 デメリット ・情報提供先のアカウントが乗っ取られると、芋づる式に ID連携先のシステムも不正ログインされる ・情報提供先に依存してしまう 　　使用制限　　　　　：情報提供先の障害や倒産によって、 ID情報が取得不可になる 　　セキュリティリスク：情報提供先で不正ログインされると乗っ取りのリスク 　　カスタマイズ不可　：ログイン画面イメージやデータ構造など このID連携を簡単に実現するためのフレームワークとして「 OpenID Connect 1.0」がある
34. © OpenID Foundation Japan 標準仕様のスペックは、 OpenID Foundationによって策定されている。 スペック上の定義では、 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである。 このプロトコルはクライアントが認可サーバーの認証結果に基づいてエンドユーザーのアイデンティティを検証可能にする . ま た同時にエンドユーザーの必要最低限のプロフィール情報を , 相互運用可能かつ RESTful な形で取得することも可能にす る。 OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. 出典元：OpenID Connect Core 1.0 incorporating errata set 1(日本語版) (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html) 原文：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid.net/specs/openid-connect-core-1_0-errata1.html) OpenID Connect 1.0 概要 34 ID連携技術の基礎 OpenID Connect 1.0は、ID連携を実現するための標準規格 ※この資料では OIDCと記載
35. © OpenID Foundation Japan ①oogle Photosにアクセ スする権限をください OpenID Connect 1.0 概要　ー　実現できること ユーザーが予約サービスに加入しようと、新たにアカウントを作成する場面である。 ユーザーは新たに予約サービスのアカウントを作成するのではなく、既に作成済の Googleアカウントを使用す ることにした。 35 ID連携技術の基礎 ②Googleアカウントにログインさせて 予約サービス ユーザー Google アカウント ①Googleアカウントを使用し、 アカウント作成を選択 ④Google 認証 ③ログインして（ログイン画面） ⑤ユーザーということが確 認できました
36. © OpenID Foundation Japan OpenID Connect 1.0 概要　ー　実現できること　 ⑦OK ⑥予約サービスにアカウントの情報 を渡していいですか？ ⑧ユーザーに同意もらったの で、情報あげます ⑨Googleアカウントで アカウント登録完了 アカウント情 報 36 ID連携技術の基礎 ①〜⑧までのやり取りの仕様を OIDC アカウント情報のことを「 ID Token」という 予約サービス ユーザー Google アカウント 予約サービス ユーザー Google アカウント
37. © OpenID Foundation Japan OpenID Connect 1.0 概要　ー　実現できること （OpenID Connect 1.0での登場人物） 37 ID連携技術の基礎 エンドユーザー （ユーザー） サービス・アプリケーションを利用する存在 Relying Party / RP（予約サービス） ID情報を提供してもらうサービス・アプリケーション OpenID Provider / OP（Google） ID情報を提供するサービス・アプリケーション ID Tokenを払い出すサーバ
38. © OpenID Foundation Japan OpenID Connect 1.0 概要 OAuth2.0は、リソースへのアクセスを行うために Access Tokenを取得する方法を定義 　→　ユーザーの属性情報を提供するための手段は定義していない 　　　（Access Tokenを持っている　≠　ユーザを特定できる ） 　→　Access Tokenを持っているで認証としてはいけない 　　　（OAuth2.0は認証で使用すべきではない） OpenID Connect1.0は、OAuth2.0認可プロセスを拡張し、 　　　　　　　　　　　　　ID連携目的で利用できるように定義 38 ID連携技術の基礎 OAuth2.0とは何が違うのか
39. © OpenID Foundation Japan 〜OAuth 2.0との違い〜 OAuth 2.0はリソースへのアクセス権を取得するために使用 OpenID Connect 1.0はユーザの属性情報取得（ ID連携）のために使用 OpenID Connect 1.0 概要　ー　実現できること 39 ID連携技術の基礎 前段の実用例のポイント ◆OpenID Connectのメリットである「サービス毎にアカウントを作成する必要がない」ため、 　ユーザーは複数のアカウント情報を保持する必要 がない ◆例ではアカウント登録のシチュエーションを示したが、 ID連携を使用した一例であり、 　ID連携を使用するユースケースは他にも存在する （詳しくは後のユースケースで紹介） 　・サービス間での連携（名寄せ）だけに使用するケース ◆OpenID Connect 1.0はOAuth 2.0にID Tokenが追加されたもの 　OpenID Connect 1.0 = OAuth 2.0 + ID Token 　ID Tokenを使用して、RP（予約サービス）はOP（Google）からユーザ情報を取得することが可能になる
40. © OpenID Foundation Japan OpenID Connect 各フロー解説 40
41. © OpenID Foundation Japan 3つのフロー 41 OAuth 2.0のAuthorization Code GrantとImplicit Grantをベースにしたものに加えて その2つを組み合わせた3つのフローが定義されている OpenID Connect 各フロー解説 Grant Type 概要 Authorization Code Flow 認可コードによりユーザーエージェントと経由せずにクライアントにアクセストークンを送信でき データの露出リスクを低減する。 Implicit Flow クライアントが直接アクセストークンを受信するため、リソースオーナーやユーザーエージェント 経由で他のアプリケーションに晒される可能性がある。 Hybrid Flow 認可リクエスト、トークンリクエストから各種トークンが返却される。
42. © OpenID Foundation Japan 各フローの特徴 42 3つのフローの特徴が示されており、どのフローを選択すればよいのか指針の参考とするとよい OpenID Connect 各フロー解説 特徴 Authorization Code Flow Implicit Flow Hybrid Flow 全てのトークンは Authorization Endpoint から返却される no yes no 全てのトークンは Token Endpoint から返却される yes no no トークンが User Agent にわたらない yes no no Client 認証が可能である yes no yes Refresh Token を利用できる yes no yes 通信が1往復だけである no yes no ほとんどの通信がサーバ間通信である yes no varies 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
43. © OpenID Foundation Japan Authorization Code Flow 43 Authorization Code Flow を利用する場合, 全てのトークンは Token Endpoint から返され る. Authorization Code Flow では Client に Authorization Code を返却し, Client はそれを 直接 ID Token および Access Token と交換する. これにより, User Agent や User Agent 上の他の不正アプリケーションなどにトークンも露 呈することがない. Authorization Server は, Authorization Code を Access Token と交換する前に Client を 認証することもできる. Authorization Code Flow は, Client Secret を Client と Authorization Server の間でセ キュアに保てる Client に適している. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
44. © OpenID Foundation Japan Authorization Code Flow 44 1. Client は必要なパラメータを含む Authentication Request を用意する. 2. Client は Authorization Server にリクエストを送信する. 3. Authorization Server は End-User を Authenticate する. 4. Authorization Server は End-User の Consent/Authorization を得る. 5. Authorization Server は Authorization Code を添えて End-User を Client に戻す. 6. Client は Token Endpoint へ Authorization Code を送信する. 7. Client は ID Token と Access Token をレスポンスボディに含むレスポンスを受け取る. 8. Client は ID Token を検証し, End-User の Subject Identifier を取得する. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
45. © OpenID Foundation Japan Authorization Code Flow 45 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクトURIで認可コードを付与 4. トークンリクエストで認可コードを送信 5. IDトークンとアクセストークン（任意でリフレッシュトークン）を返却 6. IDトークンを検証し、エンドユーザーのユーザー識別子を取得 （任意）アクセストークンでUserInfoエンドポイントからClaim（エンドユーザーの属性 情報）を取得 OpenID Connect 各フロー解説
46. © OpenID Foundation Japan Authorization Code Flow 46 OpenID Connect 各フロー解説 エンドユーザー クライアント 認可サーバー UserInfo エンドポイント ユーザーエージェント 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクト URIで認可コードを付与 5. IDトークンとアクセストークン （任意でリフレッシュトークン）を返却 （任意）アクセストークンで UserInfoエンドポイントから Claimを取得 4. トークンリクエストで認可コードを送信 6. IDトークンを検証し、 エンドユーザーのユーザー識別子を取得
47. © OpenID Foundation Japan Implicit Flow 47 Implicit Flow を利用する場合, Token Endpoint は使用されず, 全てのトークンは Authorization Endpoint から返される. Implicit Flow は主にスクリプト言語を用いて実装されブラウザ上で動作する Client によって 使用される. Access Token と ID Token は, Client に直接返却され, その Access Token と ID Token は, End-User と End-User の User Agent にアクセスするアプリケーションに露出する可 能性がある. Authorization Server は Client Authentication を行わない. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
48. © OpenID Foundation Japan Implicit Flow 48 1. Client は必要なパラメータを含む Authentication Request を用意する. 2. Client は Authorization Server にリクエストを送信する. 3. Authorization Server は End-User を Authenticate する. 4. Authorization Server は End-User の Consent/Authorization を得る. 5. Authorization Server は ID Token, および要求があれば Access Token を添えて End-User を Client に戻す. 6. Client は ID Token を検証し, End-User の Subject Identifier を取得する. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
49. © OpenID Foundation Japan Implicit Flow 49 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクトURIでIDトークンとアクセストークンを返却 4. IDトークンを検証し、エンドユーザーのユーザー識別子を取得 （任意）アクセストークンでUserInfoエンドポイントからClaimを取得 OpenID Connect 各フロー解説
50. © OpenID Foundation Japan Implicit Flow 50 OpenID Connect 各フロー解説 エンドユーザー クライアント 認可サーバー UserInfo エンドポイント ユーザーエージェント 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクト URIでIDトークンとアクセストークンを返却 （任意）アクセストークンで UserInfoエンドポイントから Claimを取得 4. IDトークンを検証し、 エンドユーザーのユーザー識別子を取得
51. © OpenID Foundation Japan Hybrid Flow 51 Hybrid Flow を使用する場合, いくつかのトークンは Authorization Endpoint から返され, その他のトークンは Token Endpoint から返される. Hybrid Flow でのトークン返却の仕組みは OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses] で指定されている. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
52. © OpenID Foundation Japan Hybrid Flow 52 1. Clientは必要なリクエストパラメータを含んだ Authentication Request を構築する. 2. Clientは Authorization Server にリクエストを送信する. 3. Authorization Server は End-User を認証する. 4. Authorization Server は End-User の同意/認可を取得する. 5. Authorization Server は End-User を Authorization Code と, レスポンスタイプに応じ た1つ以上の追加パラメータとともにClientに戻す. 6. Clientは Token Endpoint で Authorization Code を使用してレスポンスを要求する. 7. Clientは ID Token と Access Token をレスポンスボディに含んだレスポンスを受け取 る. 8. Clientは ID Token をトークンを検証し, End-User の Subject Identifier を取得する. OpenID Connect 各フロー解説 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
53. © OpenID Foundation Japan Hybrid Flow 53 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクトURIで認可コードと、要求されたIDトークンまたはアクセストークンを返 却 4. トークンリクエストで認可コードを送信 5. IDトークンとアクセストークン（任意でリフレッシュトークン）を返却 6. IDトークンを検証し、エンドユーザーのユーザー識別子を取得 （任意）アクセストークンでUserInfoエンドポイントからClaimを取得 OpenID Connect 各フロー解説
54. © OpenID Foundation Japan Hybrid Flow 54 OpenID Connect 各フロー解説 エンドユーザー クライアント 認可サーバー UserInfo エンドポイント ユーザーエージェント 1. 認証リクエスト 2. エンドユーザー認証、同意と認可 3. リダイレクト URIで認可コードと、 要求されたIDトークンまたはアクセストークンを返却 5. IDトークンとアクセストークン （任意でリフレッシュトークン）を返却 （任意）アクセストークンで UserInfoエンドポイントから Claimを取得 4. トークンリクエストで認可コードを送信 6. IDトークンを検証し、 エンドユーザーのユーザー識別子を取得
55. © OpenID Foundation Japan OAuth 2.0 と OpenID Connect の ユースケースの分類 55
56. © OpenID Foundation Japan 目次 1. 認可技術の基礎 1.1. 認可とは 1.2. OAuth 2.0 概要 1.3. OAuth 2.0 各 Grant Type 解説 2. ID 連携技術の基礎 2.1. ID 連携とは 2.2. OpenID Connect 1.0 概要 2.3. OpenID Connect 各フロー解説 3. OAuth 2.0 と OpenID Connect のユースケースの分類 3.1. OAuth 2.0 のユースケースの分類 3.2. OpenID Connect のユースケースの分類 3.3. OAuth と OIDC を組み合わせたケース 56 デジタルアイデンティティ技術 認可・ID連携 基礎
57. © OpenID Foundation Japan いくつかのフローはセキュリティ上の理由により非推奨だとされている* • OAuth 2.0 の Implicit Grant は非推奨である • OAuth 2.0 の Resource Owner Password Credentials Grant は非推奨である 非推奨でないものもあるが (Client Credentials Grant, Hybrid Flow など) 現時点ではフローごとのユースケース差について整理していない ユースケース分類の対象 57 OAuth 2.0 と OpenID Connect のユースケースの分類 POINT：Authorization Code Flow (Grant) に絞って分類する *参考：「OAuth 2.0 Security Best Current Practice (draft)」https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29
58. © OpenID Foundation Japan ユースケースを分類するために 58 OAuth 2.0 と OpenID Connect のユースケースの分類 POINT：OAuth, OIDC の登場人物を振り返る OAuth の登場人物 • リソースサーバー (RS) • 認可サーバー (AS) • クライアント • リソースオーナー OIDC の登場人物 • OpenID Provider (OP) • Relying Party (RP)
59. © OpenID Foundation Japan 以下の点に着目し、ユースケース分類を表にあらわす • 運営者 (開発者) が誰か ◦ 次に示す表では A, B, C で表現する • 同じサービスなのか、別のサービスなのか ◦ 別のサービスな場合は A’, A’’ のように表現する ◦ 同じ会社の別サービスとして開発されていることを表現したい ユースケースを分類するために 59 OAuth 2.0 と OpenID Connect のユースケースの分類 POINT：OAuth, OIDC の登場人物について注目すべきポイントを整理する
60. © OpenID Foundation Japan OAuth 2.0 のユースケースの分類 60 OAuth 2.0 と OpenID Connect のユースケースの分類
61. © OpenID Foundation Japan OAuth 2.0 のユースケースを分類してみる 61 OAuth 2.0 のユースケースの分類 POINT：最終的には以下のような表形式にまとめたい RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス, AS は IDaaS, Client は 3rd Party アプリ
62. © OpenID Foundation Japan OAuth 2.0 のユースケースを分類してみる 62 OAuth 2.0 のユースケースの分類 中間報告会では 2 ケースに絞ってご説明します RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス, AS は IDaaS, Client は 3rd Party アプリ
63. © OpenID Foundation Japan 3rd Party アプリを作るケース 63 OAuth 2.0 のユースケースの分類 RS AS Client 要求事項 ① A A’ B 3rd Party のアプリに対してフルアクセスを許可したくない 異なる開発者間でプロトコルを共有したい
64. © OpenID Foundation Japan 全て同一の事業者が運営するケース 64 OAuth 2.0 のユースケースの分類 RS AS Client 要求事項 ② A A’ A’’ クライアントごとにアクセス可能なリソースを制限する方法が必要 標準化された仕組み (OAuth のスコープ) が使える
65. © OpenID Foundation Japan OAuth 2.0 のユースケースを分類してみる 65 OAuth 2.0 のユースケースの分類 POINT：ここまでの分類を表にまとめる RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける
66. © OpenID Foundation Japan OpenID Connect のユースケースの分類 66 OAuth 2.0 と OpenID Connect のユースケースの分類
67. © OpenID Foundation Japan OpenID Connect のユースケースを分類してみる 67 OpenID Connect のユースケースの分類 POINT：最終的には以下のような表形式にまとめたい RP OP ユースケース ① A B 外部の ID 基盤で SSO するケース 例: ログイン機能を自作したくないので外部 IdP を用いる ② A A’ 自社の ID 基盤を開発するケース 例: 自社 ID を統一して UX を改善したい
68. © OpenID Foundation Japan OIDC のユースケースを分類する際の注意点 68 OIDC のユースケース分類では, リソースアクセスについて扱わない • リソースアクセスに関する分類は, OAuth の内容を流用できるため • 話が複雑になりすぎるため Relying Party (RP) と OpenID Provider (OP) の二者に単純化して考える OpenID Connect のユースケースの分類 POINT：OIDC が OAuth を拡張したものであることを踏まえて考える
69. © OpenID Foundation Japan 外部の ID 基盤で SSO するケース 69 OpenID Connect のユースケースの分類 RP OP 要求事項 ① A B 異なる事業者間でプロトコルを共有したい
70. © OpenID Foundation Japan RP OP 要求事項 ② A A’ 社内の異なる開発チーム間でプロトコルを共有したい 自社の ID 基盤を開発するケース 70 OpenID Connect のユースケースの分類
71. © OpenID Foundation Japan OpenID Connect のユースケースを分類してみる 71 OpenID Connect のユースケースの分類 POINT：ここまでの分類を表にまとめる RP OP ユースケース ① A B 外部の ID 基盤で SSO するケース 例: ログイン機能を自作したくないので外部 IdP を用いる ② A A’ 自社の ID 基盤を開発するケース 例: 自社 ID を統一して UX を改善したい
72. © OpenID Foundation Japan OAuth と OIDC を組み合わせたケース 72 OAuth 2.0 と OpenID Connect のユースケースの分類
73. © OpenID Foundation Japan OAuth と OIDC を組み合わせたケース 73 OIDC のユースケース分類では, リソースアクセスについて扱わなかった • リソースアクセスに関する分類は, OAuth の内容を流用できるため • 話が複雑になりすぎるため => OAuth のユースケースを振り返りつつ, リソースアクセスについて整理する OAuth と OIDC を組み合わせたケース POINT：「OAuth の内容を流用できる」を実際に適用しながら考える
74. © OpenID Foundation Japan OAuth と OIDC を組み合わせたケース 74 以下のような Google Calendar への API アクセスを行う予約サービスを考える • Google Account でログインできる予約サービス ◦ OpenID Connect による ID 連携 • 予約の内容を Google Calendar に登録できる ◦ OAuth 2.0 によるリソースアクセス ※ 正確には OIDC 自体にリソースアクセスに関する仕様が含まれることに注意 OAuth と OIDC を組み合わせたケース POINT：OIDC のリソースアクセスに関する側面に触れる
75. © OpenID Foundation Japan ID 連携に関する側面 75 OAuth と OIDC を組み合わせたケース POINT：OpenID Connect で扱った, 外部の ID 基盤を利用するケースと同じ
76. © OpenID Foundation Japan リソースアクセスに関する側面 76 OAuth と OIDC を組み合わせたケース POINT：OAuth 2.0 で扱った, 3rd Party アプリを作るケースと同じ
77. © OpenID Foundation Japan 2 つの側面をあわせて描く 77 OAuth と OIDC を組み合わせたケース POINT：OAuth, OIDC の組み合わせになっていることに注意
78. © OpenID Foundation Japan OIDC (ID 連携 + リソースアクセス) を使う場合 78 OAuth と OIDC を組み合わせたケース POINT：OAuth, OIDC の組み合わせになっていることに注意
79. © OpenID Foundation Japan 認可・ID連携のまとめ 79
80. © OpenID Foundation Japan • アプリ間の連携において、必要なリソースにだけアクセスできるようにする • 4 つの Grant Type がある ◦ Authorization Code, Implicit, Resource Owner Password Credentials, Client まとめ (OAuth 2.0) 80 デジタルアイデンティティ技術 認可・ID連携 基礎
81. © OpenID Foundation Japan まとめ (OpenID Connect) • OAuth のプロセスを拡張し、ID 連携に利用できるようにする • 3 つの Flow がある ◦ Authorization Code, Implicit, Hybrid 81 デジタルアイデンティティ技術 認可・ID連携 基礎
82. © OpenID Foundation Japan 登壇者紹介 認証担当 82
83. © OpenID Foundation Japan 登壇者紹介（認証担当） 83 持田 捷宏（LINEヤフー株式会社） これからIDを学びたい方でもわかるよう ミスリードがないように資料を作成しました IDに興味を持って正しく学ぶきっかけになれば幸いです 高城 勝信（株式会社ブリスコラ） APIフルライフサイクル管理をシームレスに行うプラットフォーム BAMsを開発しており、分散型の認証・認可標準の 知見も重要と考え、参画しました。 認証関連技術もたくさんあり、整理の大変さを身に染みて 感じております💦 持田さん、みなさまお疲れさまです ❗
84. © OpenID Foundation Japan 認証技術の基礎 84
85. © OpenID Foundation Japan 参考文献 出典元を明確にして 後日詳細を確認できるようにする 85
86. © OpenID Foundation Japan 参考文献と注意事項 86 # 認証技術の基礎 - 参考文献 参考文献 NIST SP 800-63-4 FIDOアライアンス W3C passkeys.dev 注意事項 わかりやすく説明をするために詳細をお伝えしきれていません 参考文献で用いられている用語は置き換えている部分があります 詳細を確認する際は一次情報をご参照ください
87. © OpenID Foundation Japan 認証標準と参考文献 87 認証の基礎 • デジタルアイデンティティ • 認証器の保証レベル（AAL） • 認証のしくみ • 認証器タイプと多要素認証 • 脅威と対策 # 認証技術の基礎 - 参考文献 FIDO標準 パスワードに代わる生体認証やセキュリティキーなどを 使用し、ユーザーのプライバシーを保護しながら フィッシングやリプレイ攻撃を防ぎ、安全で使いやすい認証 方法を提供する標準規格 U2F、UAF、 CTAP、WebAuthn 参考文献 NIST SP 800-63B-4※ 米国政府機関システムの技術要件をまとめるNISTが 提供するデジタル認証に関する包括的なガイドライン （※ not Final、Initial Public Draft） NIST SP 800-63Bsup1 パスキーとして知られる同期可能な認証器の利用を 組み込んだNIST SP 800-63Bの補足文書 W3C Web標準とガイドラインを提供する標準化団体。 本書ではWebAuthn(Level3※)に関する標準文書を参照。 （※ not W3C Recommendation、Working Draft） FIDOアライアンス FIDO標準を推進する国際団体。FIDOに関連する 各種技術ドキュメントを公開。 Passkeys.dev W3C WebAuthnコミュニティ採用グループとFIDOアライアンス のメンバーによって提供されるサイト。パスキーの利用促進のた めの情報やリソースを提供。 ※本書では、主に 太字部分をまとめて紹介しています。 パスキー
88. © OpenID Foundation Japan NIST SP 800-63-4 米国政府機関のシステムにおいて、デジタルアイデンティティサービスを実装する上で 満たすべき技術的要件をまとめたガイドライン 88 # 認証技術の基礎 - 参考文献 Digital Identity Guidelines, NIST SP 800-63-4 (Initial Public Draft), National Institute of Standards and Technology, https://doi.org/10.6028/NIST.SP.800-63-4.ipd を日本語訳した文献を参考にしています Initial Public Draftであり最終確定版ではありません 本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり , それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
89. © OpenID Foundation Japan FIDOアライアンス パスワードへの過度の依存を減らすための認証に関する標準化団体 89 # 認証技術の基礎 - 参考文献 参考元：「FIDOアライアンスの概要 - 認証の本質を変える」 https://fidoalliance.org/overview/?lang=ja
90. © OpenID Foundation Japan W3C Webに関する標準とガイドラインを提供する標準化団体 90 「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 を参考にしています Working DraftでありW3C standards, W3C Recommendationではありません # 認証技術の基礎 - 参考文献 The World Wide Web Consortium (W3C) develops standards and guidelines to help everyone build a web based on the principles of accessibility, internationalization, privacy and security. 引用：「W3C」https://www.w3.org/ Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive license rules apply.
91. © OpenID Foundation Japan passkeys.dev FIDOアライアンスやW3Cのメンバーによって提供されている、FIDO認証導入に役立つ 情報をまとめたサイト 91 # 認証技術の基礎 - 参考文献 passkeys.dev is brought to you by the W3C WebAuthn Community Adoption Group and members of the FIDO Alliance. 引用：passkeys.dev「About | passkeys.dev」https://passkeys.dev/about/. Licensed under CC BY-SA 4.0.
92. © OpenID Foundation Japan デジタル アイデンティティ 認証する対象である デジタルアイデンティティの概念 を理解する 92
93. © OpenID Foundation Japan デジタルアイデンティティ 電子的に表現されたユーザーのアイデンティティ 93 # 認証技術の基礎 - デジタルアイデンティティ # Digital Authentication 情報システムに対して , 電子的に表現されたユーザーの Identity の確からしさを確立するプロセス . SP 800-63 の前エディションまでは Electronic Authentication と呼ばれていたもの. 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
94. © OpenID Foundation Japan アイデンティティ 特定の集団において、特定の人や物を他と区別できる特徴や特徴の集合 94 # 認証技術の基礎 - デジタルアイデンティティ # Identity 特定のコンテキストにおいて , ある Subject を他と区別できるかたちで表現する , Attribute ないしは Attribute の 集合. # Subject 人間, 組織, デバイス, ハードウェア, ネットワーク, ソフトウェア, サービスなど. # Attribute 人や物に関する生来の性質や特徴 . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
95. © OpenID Foundation Japan • 会社において、自分を他と区別できる、社員番号、姓名や所属部署の集合 • 国　において、自分を他と区別できる、マイナンバー、姓名や住所の集合 ### 勤務先の会社 ### 具体例 95 # 認証技術の基礎 - デジタルアイデンティティ • 社員番号 • 姓名 • 所属部署 • … アイデンティティ ### 日本の国民 ### • マイナンバー • 姓名 • 住所 • … アイデンティティ
96. © OpenID Foundation Japan 認証とは 認証への理解を深めるために 認証の 定義 / 必要性(目的) / 方法 を理解する 96
97. © OpenID Foundation Japan ① メールサービスが提供されているサイトにアクセスする 認証のイメージ 97 # 認証技術の基礎 - 認証とは ようこそ！ Exampleメール サインイン ①
98. © OpenID Foundation Japan ② メールサービスから認証を要求される 認証のイメージ 98 # 認証技術の基礎 - 認証とは example_id ******* ID パスワード ようこそ！ Exampleメール サインイン ① ②
99. © OpenID Foundation Japan ③ IDとパスワードを入力して認証する 認証のイメージ 99 # 認証技術の基礎 - 認証とは example_id ******* ID パスワード （認証完了✅） ようこそ！ Exampleメール サインイン ① ② ③
100. © OpenID Foundation Japan ④ 認証が完了することでメールサービスを利用できる 認証のイメージ 100 # 認証技術の基礎 - 認証とは example_id ******* ID パスワード （認証完了✅） ようこそ！ Exampleメール サインイン Exampleメール 件名：AAA 件名：BBB 件名：CCC ① ② ④ ③
101. © OpenID Foundation Japan 認証の定義（重要） デジタルアイデンティティの確からしさを確立するプロセス 101 # 認証技術の基礎 - 認証とは # Digital Authentication 情報システムに対して , 電子的に表現されたユーザーの Identity の確からしさを確立するプロセス . SP 800-63 の前エディションまでは Electronic Authentication と呼ばれていたもの. 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
102. © OpenID Foundation Japan デジタルアイデンティティの確からしさを確立するため （→デジタルアイデンティティの意図しない利用を防ぐため） ### 勤務先の会社 ### ### メールサーバー ### Aさんメールフォルダ 認証の必要性（目的） 102 # 認証技術の基礎 - 認証とは • 社員番号 • 姓名 • 所属部署 • … アイデンティティ Bさんメールフォルダ
103. © OpenID Foundation Japan 認証の方法 デジタルアイデンティティを主張するために使用される1つまたは複数の認証器の妥当 性を判断する 103 # 認証技術の基礎 - 認証とは # Authentication Digital Identity を主張するために使用される 1 つまたは複数の Authenticator の妥当性を判断するプロセス . Authentication は, デジタル・サービスにアクセスしようとする Subject が, Authenticate に使用される技術を管 理下に置いていることを証明する . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
104. © OpenID Foundation Japan パスワードの妥当性を判断している 104 # 認証技術の基礎 - 認証とは example_id ******* ID パスワード （認証完了✅） ようこそ！ Exampleメール サインイン Exampleメール 件名：AAA 件名：BBB 件名：CCC ① ② ④ ③ パスワード認証における認証方法
105. © OpenID Foundation Japan 認証の仕組み 認証する時の 人とサーバーとのやりとり を理解する 105
106. © OpenID Foundation Japan 認証のイメージ 106 # 認証技術の基礎 - 認証とは example_id ******* ID パスワード （認証完了✅） ようこそ！ Exampleメール サインイン Exampleメール 件名：AAA 件名：BBB 件名：CCC ① ② ④ ③
107. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例 107 # 認証技術の基礎 - 認証の仕組み
108. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例（抽象化） 108 # 認証技術の基礎 - 認証の仕組み 対応表 ユーザー 人物（Subject）＊認証（もしくは身元確認）が完了したSubject：Subscriber Exampleメール デジタルアイデンティティサービス サービス提供システム（RP） 検証システム（Verifier） デジタルアイデンティティ管理システム （CSP） デジタルアイデンティティDB （Claimantが保存される）
109. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例（抽象化）1/3 109 # 認証技術の基礎 - 認証の仕組み
110. © OpenID Foundation Japan ＊認証方法によって差分があるシーケンス図の例になります パスワード認証におけるシーケンス図の例（抽象化）2/3 110 # 認証技術の基礎 - 認証の仕組み
111. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例（抽象化）3/3 111 # 認証技術の基礎 - 認証の仕組み
112. © OpenID Foundation Japan NIST SP 800-63-4に、シーケンス図の例が紹介されています 【紹介】シーケンス図の例 112 # 認証技術の基礎 - 認証の仕組み 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
113. © OpenID Foundation Japan NIST SP 800-63-4に、より抽象的に表現されたデジタルアイデンティティモデルが紹介 されています 【紹介】デジタルアイデンティティモデル 113 # 認証技術の基礎 - 認証の仕組み 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
114. © OpenID Foundation Japan 脅威と対策 114
115. © OpenID Foundation Japan 認証に対する脅威と その脅威に対する対策 を理解する 脅威と対策 115
116. © OpenID Foundation Japan 脅威のイメージ 116 # 脅威と対策 example_id ******* ID パスワード （認証完了✅） ようこそ！ Exampleメール サインイン Exampleメール 件名：AAA 件名：BBB 件名：CCC ① ② ④ ③ IDとパスワードを 盗み見られた IDとパスワードを 推測された IDとパスワードが 流出した IDとパスワードを 書いた紙を無くした 認証完了を証明する 情報を盗まれた フィッシングサイト
117. © OpenID Foundation Japan 脅威の定義 デジタルアイデンティティの利用について、登録した人物に対して、許可をとっていない 人が、サービスを騙して、登録した人物だと、信じ込ませること 117 # 脅威と対策 # Attack Authorize されていない主体が , Verifier や RP をだまして当該個人を Subscriber だと信じ込ませようとする行 為. 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
118. © OpenID Foundation Japan デジタルアイデンティティの確からしさを確立するため （→デジタルアイデンティティの意図しない利用を防ぐため） ### 勤務先の会社 ### ### メールサーバー ### Aさんメールフォルダ 認証の必要性（目的） 118 # 認証技術の基礎 - 認証とは　（再掲） • 社員番号 • 姓名 • 所属部署 • … アイデンティティ Bさんメールフォル
119. © OpenID Foundation Japan 脅威の種類 119 # 脅威と対策 脅威 説明 盗難 ⚠認証に使用するデバイスが盗まれる 複製（露呈） ⚠認証に使用する情報が複製される 盗聴 ⚠認証に使用する情報が通信の経路で盗み見られる フィッシング ⚠正規サービスだと思い込ませて認証に使用する情報を搾取される 表は 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html の情報を参考にしています
120. © OpenID Foundation Japan 認証の方法ごとの特性を理解し脅威を許容/軽減することでサービスに適した 認証方法の提供が可能 脅威の対策 120 # 脅威と対策 脅威 対策（具体例） 盗難 ✅ 指紋や顔等の情報を利用する 複製 ✅ 文字列長の長いパスワードをパスワードマネージャーで管理する 盗聴 ✅ TLSで保護された経路で認証をする フィッシング ✅ FIDO認証（パスキー）を利用する 表は 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html の情報を参考にしています
121. © OpenID Foundation Japan 認証の方法ごとの特性を理解し脅威を許容/軽減することでサービスに適した 認証方法の提供が可能 脅威の対策 121 # 脅威と対策 脅威 対策（具体例） 盗難 ✅ 指紋や顔等の情報を利用する 複製 ✅ 文字列長の長いパスワードをパスワードマネージャーで管理する 盗聴 ✅ TLSで保護された経路で認証をする フィッシング ✅ FIDO認証（パスキー）を利用する 脅威を完全に排除することはできないため 認 証 方 法 にはそれぞれどんな 脅 威 がありどんな 対 策 （ 軽 減 ）ができるか 理解した上で自サービスで提供すべき認証方法を選ぶ必要がある
122. © OpenID Foundation Japan 認証要素 脅威に対する対策として 認証要素ごとに特性が異なり脅威も異なるため 認証要素を組み合わせることで脅威を軽減することが可能 122 # 脅威と対策 認証要素 具体例[*] 脅威の一例 記憶 パスワード 露呈 所持 IDカード 盗難 生体 指紋 複製 [*]あくまで認証方法の具体例ではなく認証要素の具体例です
123. © OpenID Foundation Japan パスキーの基礎 123
124. © OpenID Foundation Japan パスキーとは 124 パスキーへの理解を深めるために パスキーの定義 パスキーとFIDOの関係性 を理解する
125. © OpenID Foundation Japan 認証の方法ごとの特性を理解し脅威を許容/軽減することでサービスに適した 認証方法の提供が可能 脅威の対策 125 # 脅威と対策　（再掲） 脅威 対策（具体例） 盗難 ✅ 指紋や顔等の情報を利用する 複製 ✅ 文字列長の長いパスワードをパスワードマネージャーで管理する 盗聴 ✅ TLSで保護された経路で認証をする フィッシング ✅ FIDO認証（パスキー）を利用する 表は 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html の情報を参考にしています
126. © OpenID Foundation Japan ① メールサービスが提供されているサイトにアクセスする パスキーを利用した認証のイメージ 126 # パスキーの基礎 - パスキーとは ようこそ！ Exampleメール サインイン ①
127. © OpenID Foundation Japan ② 認証に使用するパスキーを選択する パスキーを利用した認証のイメージ 127 # パスキーの基礎 - パスキーとは ようこそ！ Exampleメール サインイン ① ② example_id_A ID example_id_B example_id_C
128. © OpenID Foundation Japan ③ 顔認証をする パスキーを利用した認証のイメージ 128 # パスキーの基礎 - パスキーとは ようこそ！ Exampleメール サインイン ① ③ 顔認証をしてください ② example_id_A ID example_id_B example_id_C
129. © OpenID Foundation Japan ④ 認証が完了することでメールサービスを利用できる パスキーを利用した認証のイメージ 129 # パスキーの基礎 - パスキーとは ようこそ！ Exampleメール サインイン ① ② ③ 顔認証をしてください Exampleメール 件名：AAA 件名：BBB 件名：CCC ④ example_id_A ID example_id_B example_id_C
130. © OpenID Foundation Japan パスキーの定義（重要） FIDO標準を利用した認証（FIDO認証）で利用される ディスカバラブルFIDOクレデンシャル 130 # パスキーの基礎 - パスキーとは # Passkey The high level, end-user centric term for a FIDO2/WebAuthn Discoverable Credential. Like “password”, “passkey” is a common noun intended to be used in every day conversations and experiences. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. FIDOクレデンシャル ディスカバラブルFIDOクレデンシャル 参考元：「FAQ's - FIDO Alliance」https://fidoalliance.org/faqs
131. © OpenID Foundation Japan パスキーの種類 同期パスキーとデバイス固定パスキーの2種類ある 131 # パスキーの基礎 - パスキーとは # Passkey From the technical side, there are two flavors of passkeys: synced and device-bound. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. FIDOクレデンシャル ディスカバラブルFIDOクレデンシャル（パスキー） 同期パスキー デバイス固定パスキー
132. © OpenID Foundation Japan 同期パスキーとデバイス固定パスキーの定義 132 # パスキーの基礎 - パスキーとは 同期パスキー パスワード検証など不要で認証要求時に常に利用可能なディスカバラブル FIDOクレデンシャル デバイス固定パスキー 単一の認証器に紐づくデバイスから離れることがないディスカバラブル FIDOクレデンシャル # Synced passkey A FIDO2 Discoverable Credential that can reliably be used for bootstrapping sign-in, without requiring other login challenges such as passwords and OTPs. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. # Device-bound passkey A FIDO2 Discoverable Credential that is bound to a single authenticator. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0.
133. © OpenID Foundation Japan 認証の方法 デジタルアイデンティティを主張するために使用される1つまたは複数の認証器の妥当 性を判断する 133 # 認証技術の基礎 - 認証とは　（再掲） # Authentication Digital Identity を主張するために使用される 1 つまたは複数の Authenticator の妥当性を判断するプロセス . Authentication は, デジタル・サービスにアクセスしようとする Subject が, Authenticate に使用される技術を管 理下に置いていることを証明する . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
134. © OpenID Foundation Japan FIDO標準[*]によりFIDOクレデンシャルの妥当性を判断するプロセス ∟ FIDO UAF [*][*1] / CTAP1 (FIDO U2F) [*1] 　　/ FIDO2 (WebAuthn [*][*2] + CTAP2 [*1]) [*1] FIDOアライアンスで公開されているFIDO仕様 [*2] W3Cで公開されているWeb仕様 [*] 公開鍵暗号方式採用 / フィッシング耐性あり (UAF:appId/WebAuthn:rpId) FIDO認証とは 134 # パスキーの基礎 - パスキーとは 参考元：「FAQ's - FIDO Alliance」https://fidoalliance.org/faqs
135. © OpenID Foundation Japan FIDOクレデンシャルの妥当性を判断している パスキーを利用した認証のイメージ 135 # パスキーの基礎 - パスキーとは ようこそ！ Exampleメール サインイン ① ③ 顔認証をしてください Exampleメール 件名：AAA 件名：BBB 件名：CCC ④ ② example_id_A ID example_id_B example_id_C
136. © OpenID Foundation Japan WebAuthnの 仕組み 136 FIDO2の基礎となる仕様である WebAuthnの概要 FIDOクレデンシャルの作成と使用 を理解する
137. © OpenID Foundation Japan FIDO標準[*]によりFIDOクレデンシャルの妥当性を判断するプロセス ∟ FIDO UAF [*][*1] / CTAP1 (FIDO U2F) [*1] 　　/ FIDO2 (WebAuthn [*][*2] + CTAP2 [*1]) [*1] FIDOアライアンスで公開されているFIDO仕様 [*2] W3Cで公開されているWeb仕様 [*] 公開鍵暗号方式採用 / フィッシング耐性あり (UAF:appId/WebAuthn:rpId) FIDO認証とは 137 # パスキーの基礎 - パスキーとは　（再掲） 参考元：「FAQ's - FIDO Alliance」https://fidoalliance.org/faqs
138. © OpenID Foundation Japan ウェブ上で公開鍵暗号方式ベースのクレデンシャルの作成と使用を可能にするAPIを定 義した仕様書 WebAuthnとは 138 # パスキーの基礎 - WebAuthnの仕組み # Abstract This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. 引用：「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
139. © OpenID Foundation Japan アテステーションとアサーション 139 # パスキーの基礎 - WebAuthnの仕組み # 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 アテステーション 特定の認証器が作成したデータであるという検証可能な証拠（証明書を含むオブジェクト） アサーション 認証器が作成する秘密鍵で署名されたオブジェクト
140. © OpenID Foundation Japan 【認証方法の紐付け】 FIDOクレデンシャルの 作成 140
141. © OpenID Foundation Japan ある人物に関する情報を収集, 確認, および検証するプロセス 【補足】身元確認 141 # パスキーの基礎 - WebAuthnの仕組み # Identity Proofing CSP が Credential 発行のためにある人物に関する情報を収集 , 確認, および検証するプロセス . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
142. © OpenID Foundation Japan ① 認証（もしくは身元確認）が完了した状態でFIDO認証登録画面を開く FIDO認証を紐付ける時のイメージ 142 # パスキーの基礎 - WebAuthnの仕組み Exampleメール FIDO認証登録画面 ① FIDOクレデンシャルを登録する
143. © OpenID Foundation Japan ② 顔認証をする FIDO認証を紐付ける時のイメージ 143 # パスキーの基礎 - WebAuthnの仕組み Exampleメール FIDO認証登録画面 ② Exampleメール FIDO認証登録画面 ① FIDOクレデンシャルを登録する 顔認証をしてください
144. © OpenID Foundation Japan ③ FIDO認証の登録が完了する FIDO認証を紐付ける時のイメージ 144 # パスキーの基礎 - WebAuthnの仕組み Exampleメール FIDO認証登録画面 ② Exampleメール FIDO認証登録画面 （登録完了✅） ③ Exampleメール FIDO認証登録画面 ① FIDOクレデンシャルを登録する 顔認証をしてください
145. © OpenID Foundation Japan FIDO認証を紐付ける時のシーケンス図の例 1/2 145 # パスキーの基礎 - WebAuthnの仕組み
146. © OpenID Foundation Japan FIDO認証を紐付ける時のシーケンス図の例 2/2 146 # パスキーの基礎 - WebAuthnの仕組み
147. © OpenID Foundation Japan W3Cに、FIDOクレデンシャル登録フローが紹介されています 【紹介】FIDOクレデンシャル登録フロー 147 # 認証技術の基礎 - 認証の仕組み 引用：「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
148. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例（抽象化） 148 # 認証技術の基礎 - 認証の仕組み　（再掲） 対応表 ユーザー 人物（Subject）＊認証（もしくは身元確認）が完了したSubject：Subscriber Exampleメール デジタルアイデンティティサービス サービス提供システム（RP） 検証システム（Verifier） デジタルアイデンティティ管理システム （CSP） デジタルアイデンティティDB （Claimantが保存される）
149. © OpenID Foundation Japan FIDO認証を紐付ける時のシーケンス図の例（抽象化）1/2 149 # パスキーの基礎 - WebAuthnの仕組み
150. © OpenID Foundation Japan FIDO認証を紐付ける時のシーケンス図の例（抽象化）2/2 150 # パスキーの基礎 - WebAuthnの仕組み
151. © OpenID Foundation Japan 【認証】 FIDOクレデンシャルの 使用 151
152. © OpenID Foundation Japan パスキーを利用した認証のイメージ 152 # パスキーの基礎 - パスキーとは　（再掲） ようこそ！ Exampleメール サインイン ① ③ 顔認証をしてください Exampleメール 件名：AAA 件名：BBB 件名：CCC ④ ② example_id_A ID example_id_B example_id_C
153. © OpenID Foundation Japan FIDO認証のシーケンス図の例 1/3 153 # パスキーの基礎 - WebAuthnの仕組み
154. © OpenID Foundation Japan FIDO認証のシーケンス図の例 1/3 154 # パスキーの基礎 - WebAuthnの仕組み # フィッシング耐性 FIDOクレデンシャルはFIDOクレデンシャルを 登 録 したウェブサーバーのOrigin に紐づく フィッシングサイトは 正 規 WebサービスのOriginをホスティングできないため フィッシング耐性があると言える
155. © OpenID Foundation Japan FIDO認証のシーケンス図の例 2/3 155 # パスキーの基礎 - WebAuthnの仕組み
156. © OpenID Foundation Japan FIDO認証のシーケンス図の例 2/3 156 # パスキーの基礎 - WebAuthnの仕組み # 公開鍵暗号方式 認証器が管理するFIDOクレデンシャルの中には秘密鍵が含まれる FIDOクレデンシャル登録時にデジタルアイデンティティサービスに登録した公開 鍵の対となっており認証において秘密鍵自体は認証器の外に出ない
157. © OpenID Foundation Japan FIDO認証のシーケンス図の例 3/3 157 # パスキーの基礎 - WebAuthnの仕組み
158. © OpenID Foundation Japan W3Cに、FIDO認証フローが紹介されています 【紹介】FIDO認証フロー 158 # 認証技術の基礎 - 認証の仕組み 引用：「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
159. © OpenID Foundation Japan パスワード認証におけるシーケンス図の例（抽象化） 159 # 認証技術の基礎 - 認証の仕組み　（再掲） 対応表 ユーザー 人物（Subject）＊認証（もしくは身元確認）が完了したSubject：Subscriber Exampleメール デジタルアイデンティティサービス サービス提供システム（RP） 検証システム（Verifier） デジタルアイデンティティ管理システム （CSP） デジタルアイデンティティDB （Claimantが保存される）
160. © OpenID Foundation Japan FIDO認証のシーケンス図の例（抽象化） 1/3 160 # パスキーの基礎 - WebAuthnの仕組み
161. © OpenID Foundation Japan FIDO認証のシーケンス図の例（抽象化） 2/3 161 # パスキーの基礎 - WebAuthnの仕組み
162. © OpenID Foundation Japan FIDO認証のシーケンス図の例（抽象化） 3/3 162 # パスキーの基礎 - WebAuthnの仕組み
163. © OpenID Foundation Japan 同期パスキーにおける脅威 を理解する 同期パスキーに おける脅威 163
164. © OpenID Foundation Japan 同期パスキーとデバイス固定パスキーの定義 164 # パスキーの基礎 - パスキーとは　（再掲） 同期パスキー パスワード検証など不要で認証要求時に常に利用可能なディスカバラブル FIDOクレデンシャル デバイス固定パスキー 単一の認証器に紐づくデバイスから離れることがないディスカバラブル FIDOクレデンシャル # Synced passkey A FIDO2 Discoverable Credential that can reliably be used for bootstrapping sign-in, without requiring other login challenges such as passwords and OTPs. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. # Device-bound passkey A FIDO2 Discoverable Credential that is bound to a single authenticator. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0.
165. © OpenID Foundation Japan 同期パスキーにおける脅威の種類 165 # 同期パスキーにおける脅威 脅威 説明 同期された秘密鍵の制御喪失 ⚠他のユーザーの端末に秘密鍵を同期されることで 意図せず秘密鍵が利用される 同期ファブリックの侵害 ⚠同期ファブリックからの秘密鍵の漏洩が起こりうる アカウント復旧による不正アクセス ⚠アカウント復旧による同期ファブリックへのアクセスで 意図せず秘密鍵が利用される 秘密鍵の失効 ⚠秘密鍵が流出しても無効化できない 表は Incorporating Syncable Authenticators Into NIST SP 800-63B, NIST Special Publication 800 NIST SP 800-63Bsup1, National Institute of Standards and Technology, https://doi.org/10.6028/NIST.SP.800-63Bsup1 の情報を参考にしています
166. © OpenID Foundation Japan 同期パスキーにおける脅威の対策 同期パスキーにも脅威はあるため 特性を理解し脅威を許容/軽減した上で提供することが必要である 166 # 同期パスキーにおける脅威 脅威 説明 同期された秘密鍵の制御喪失 ✅同期パスキー提供事業者が 秘密鍵の共有に関する情報をユーザーに通知する 同期ファブリックの侵害 ✅同期パスキー提供事業者が 秘密鍵は暗号化された状態で保存する アカウント復旧による不正アクセス ✅同期パスキー提供事業者が アカウント復旧したことをユーザーに通知する 秘密鍵の失効 ✅同期パスキー提供事業者が秘密鍵の漏洩等の事実を元に 秘密鍵を失効させる仕組みを提供する 表は Incorporating Syncable Authenticators Into NIST SP 800-63B, NIST Special Publication 800 NIST SP 800-63Bsup1, National Institute of Standards and Technology, https://doi.org/10.6028/NIST.SP.800-63Bsup1 の情報を参考にしています
167. © OpenID Foundation Japan 認証のまとめ 167
168. © OpenID Foundation Japan 認証の基礎 168 # 認証のまとめ 定義 デジタルアイデンティティの確からしさを確立するプロセス 目的 デジタルアイデンティティの確からしさを確立するため （→デジタルアイデンティティの意図しない利用を防ぐため） 方法 デジタルアイデンティティを主張するために使用される 1つまたは複数の認証器の妥当性を判断する
169. © OpenID Foundation Japan パスキーの基礎 169 # 認証のまとめ パスキー FIDO認証で利用されるディスカバラブル FIDOクレデンシャル FIDO認証 FIDO標準によりFIDOクレデンシャルの妥当性を判断するプロセス FIDO標準 公開鍵暗号方式 / フィッシング耐性あり WebAuthn FIDO2標準の基礎 ウェブ上で公開鍵暗号方式ベースのクレデンシャルの作成と使用を可能にする APIを定義した仕様書
170. © OpenID Foundation Japan 取り組みで感じた課題 170
171. © OpenID Foundation Japan 用語、概念、定義の解説 171 【初版】ほぼ用語や概念の説明（引用）しかない資料 • 情報過多 • 定義は抽象度が高く具体との紐付きがないと理解（イメージ）しづらい 【今回の資料】引用しつつも説明するスコープを狭めて具体を交えた資料 • 初版で説明していたがこの資料では説明できていない範囲がある • 細かい説明を省いているため説明していない部分への疑問が残る 仕様や概要等を説明する際にミスリードなくわかりやすく説明する上で 気をつけていること/大事にしていること/工夫があればお聞きしたいです 取り組みで感じた課題
172. © OpenID Foundation Japan 認可技術、ID連携技術の基礎 172 • OAuth2.0でできることを初学者向けにどのように説明すればいいのか。 • 実例をポンチ図を使用して表現することで入りやすいものにした。 • OAuthとOIDCのと違いを初学者向けの説明をどうするとわかりやすいかを悩みま した。 • 現時点では、言葉のもの説明になっているので、絵や図の視覚的説明も入れると わかりやすいかもと思っています。 取り組みで感じた課題
173. © OpenID Foundation Japan OAuth 2.0 と OpenID Connect のユースケースの分類 173 • どういった基準に従ってユースケースを分類すべきか。今回は登場人物に着目した が、クライアントの種類やフローなど、他にも分け方は多数ありそう • どのフローを扱うべきか。「Implicit をこう使うと危険だよ」といった説明もできるが、 「非推奨なのでそもそも解説しない」といった整理も可能 取り組みで感じた課題
174. © OpenID Foundation Japan 既存仕様と最新仕様を織り交ぜた整理の難しさ 174 • 認証パートをまとめるにあたって、初学者にもわかりやすくという目的が あるものの、権威ある公開文書を参照するといった制約とパスキーなど 最新技術の動向も踏まえるといった困難さがあったため、資料大枠の整理を ある程度属人的に行わざるを得ず全体が整うまでに時間がかかった。 • 今後も、多要素認証を含む認証器9タイプやWebAuthnのフローなど 本資料への追加候補のネタがあるので、全体をどのように整理するかの 地図を最初に描いて進めるようにできたらよい。 取り組みで感じた課題
175. © OpenID Foundation Japan EOP 175
176. © OpenID Foundation Japan Appendix 176
177. © OpenID Foundation Japan OAuth 2.0 の非推奨のフローについて 177 • Implicit Grant ◦ Access Token の漏洩およびリプレイに対して脆弱なため ◦ > “The implicit grant (response type "token") and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Section 4.1, Section 4.2, Section 4.3, and Section 4.6.” 引用元：「OAuth 2.0 Security Best Current Practice」https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-implicit-grant ◦ OIDC の Implicit Flow (response_type=id_token) は非推奨の対象でない • Resource Owner Password Credentials Grant ◦ Client に対して安全でない方法でクレデンシャルが渡ってしまうため ◦ Client が無害であっても、攻撃対象が拡大するため ◦ > “The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the authorization server) and users are trained to enter their credentials in places other than the authorization server.” 引用元：「OAuth 2.0 Security Best Current Practice」https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-resource-owner-password-cre Appendix Implicit Grant と Resource Owner Password Credentials Grant は非推奨
178. © OpenID Foundation Japan なぜ OAuth, OIDC の登場人物に着目して分類したか 178 • OAuth の活用が 3rd Party アプリへの適用に限定されないことを示す • リソースアクセスに係る関係性と、ID 連携のための関係性を分離して考える • 共通仕様に則るべきポイントを明確にする ◦ AS, RS と Client を別の事業者が作るなら、リソースアクセスの制御方法の共有が必要 ◦ AS と RS を別の事業者が作るなら、 Access Token を解釈する方法の共有が必要 • アクセス制御を行う手段を考えやすくする ◦ RS と Client が同一アプリならアクセス制御に関わる情報の連携が不要 Appendix
179. © OpenID Foundation Japan なぜ OAuth, OIDC の登場人物に着目して分類したか 179 Appendix RS と Client が同一なら OAuth は不要、のように整理できる RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス・AS は IDaaS・Client は 3rd Party アプリ ⑤ A B A クライアントとアプリが一体であるケース サービス間連携を前提としたアクセス制御の仕組みは不要
180. © OpenID Foundation Japan なぜ OAuth でリソースアクセスを制御できるのか 180 OAuth のアクセストークンに紐づいている内容 (例) • scope：アクセス範囲を表現する文字列 • sub：リソースオーナーの識別子 • exp：トークンの有効期限 上記は RFC 7622 OAuth 2.0 Token Introspection で示されたパラメーターの一部 OAuth のコア部分 (RFC 6749) では特に定義されていない Appendix POINT：アクセストークンを用いてアクセス可能な範囲を判断できる 参考：「OAuth 2.0 Token Introspection」 https://datatracker.ietf.org/doc/html/rfc7662
181. © OpenID Foundation Japan なぜ OAuth でリソースアクセスを制御できるのか 181 Appendix POINT：RS は AS にアクセストークンの内容を確認する
182. © OpenID Foundation Japan OAuth クライアントのクライアントタイプ コンフィデンシャル (confidential) “クレデンシャルの機密性を維持することができるクライアント (例えば, クライアントクレデンシャルへのア クセスが制限されたセキュアサーバー上に実装されたクライアント ), または他の手段を使用したセキュア なクライアント認証ができるクライアント .” パブリック (public) “(例えば, インストールされたネイティブアプリケーションやブラウザベースの Webアプリケーションなど , リ ソースオーナーのデバイス上で実行されるクライアントのように ) クライアントクレデンシャルの機密性を維 持することができず, かつ他の手段を使用したセキュアなクライアント認証もできないクライアント .” 182 Appendix POINT：OAuth では 2 種類のクライアントタイプが定義されている 引用：「The OAuth 2.0 Authorization Framework」 https://openid-foundation-japan.github.io/rfc6749.ja.html#client-types
183. © OpenID Foundation Japan OAuth クライアントのクライアントタイプ コンフィデンシャルクライアント (Confidential Client) • クレデンシャルの機密性を維持することができるクライアント ◦ 機密性：クライアントシークレットを安全に保持できるか？など • 例：サーバーを持つ Web アプリケーション パブリッククライアント (Public Client) • クレデンシャルの機密性を維持できないクライアント • 例：SPA, ネイティブアプリ 183 Appendix POINT：仕様書の内容を簡潔にまとめてみる
184. © OpenID Foundation Japan クライアントタイプに応じた仕様設計 184 Appendix 例：モバイルアプリはパブリッククライアントなので、画像の編集を許可しない