認証認可を通して学ぶ、『わからない』のつぶし方(仮) - ID沼入口 発表資料

“ID沼入口” - 基本とセキュリティから始める、考え続けるためのID管理技術勉強会 で発表を行う資料です。
現在作成中のため、変更のある可能性があります。

https://openid.connpass.com/event/396041/

Transcript

1. SLIDE TEMPLATE 認証認可を通して学ぶ 『わからない』のつぶし方 @calloc134 ID 沼入門 — 認証認可プロトコルの長い道のりをどう学ぶか
2. かろっく @calloc134 右下の QR からプロフィールへ → 自己紹介 Web アプリとセキュリティ が好きな社会人一年生 フロントエンドは React + TypeScript バックエンドは Hono などをよく触る。最近はお仕事でGoやPHP インフラは少し。メインPCはLinux、家のルータはOpenWrt 基本的にWebアプリ・クラウドネイティブ・コンテナ周りに興味がある 認証認可・Web セキュリティの沼 に片足を突っ込み中 コードリーディングを楽しむ人 (ReactやPostgreSQL) @calloc134 2
3. 対象とする人 話すこと 認証認可プロトコルの理解はなぜ難しい か 認証認可プロトコルをどう学ぶ か 認証認可プロトコルの理解をどう実際の防御に活かす か 仕様を一から学ぼうとして挫折した人 一通り仕様を勉強したはいいものの、表面をなぞっただけで腹落ちしていない と感じる人 仕様をちゃんと理解することで、どう実際の防御に活かせるのか を知りたい人 @calloc134 3
4. 目次 OAuth/OIDC 仕様の学習の難しさ 1 認証認可プロトコル学習のコツ 2 仕様をもとに読み解くリアルワールド実装 3 まとめ 4 @calloc134 4
5. S E C T I O N / 0 1 OAuth/OIDC 仕様の 学習の難しさ @calloc134 5
6. そもそもOAuth/OIDC の学習は構造的に難しい OAuth/OIDC 仕様の学習の難しさ 仕様の多さ 1 依存関係の複雑さ 2 現実世界の実装のわかりづらさ 3 @calloc134 6
7. 関連仕様が多く全体図が見えない OAuth 2.0 だけでも いきなり仕様を読むと心が折れがち ※ 余談: 重要な仕様は OAuth 2.1 として集約が進んでいる 仕様が多い RFC6749 OAuth 2.0 RFC9700 OAuth 2.0 Security BCP RFC6750 Bearer Token Usage RFC7636 PKCE … @calloc134 7
8. ある概念を理解するために 別の仕様を前提 としていることが多い 例: 「Q. 認可コードフローは何故認可コードを挟むのか？」 前提となる知識 ここまで履修してようやく最初の質問に答えることが出来る 依存関係の複雑さ (1) Implicit Flow の存在 Confidential Client / Public Client の違い フロントチャネル露出のリスク PKCE の存在 トークン交換をどう結びつけるか Implicit Flow だと PKCEを挟み込む余地がないこと @calloc134 8
9. → 学習順序が難しい 最初は「おまじない」としてスルーし、後から理解するのが吉。 つまり 周回が必要なコンテンツ 。 依存関係の複雑さ (2) @calloc134 9
10. 特に、フロントエンド界隈の人間が目にしがちな実装 初学者目線だと 実はこの実装は結構クセのある用法 。いきなりラスボスに挑むようなもの 更にこの構成を「普通だ」と思ってしまうと、本来の用途の理解の妨げ にもなる 現実世界の身近な実装のわかりづらさ Auth0 や Firebase などの IdP を利用 フロントエンドからアクセストークンを取得 フロントエンドからバックエンドにアクセストークンを渡す アクセストークンを使ってログイン状態を管理 技術上は OAuth だが、リソース認可ではなくログイン用途に見え 混乱する Public Client で動作するが、初学者がいきなり Public Client を考えるのは難しい @calloc134 10
11. このセクションのまとめ OAuth/OIDC の学習は構造的に難しい 仕様の多さ いきなり仕様を読むと心が折れがち 依存関係の複雑さ 学習順序が難しい 周回が前提のコンテンツ 現実世界の実装のわかりづらさ 身近な実装が実はクセのある用法 @calloc134 11
12. S E C T I O N / 0 2 認証認可プロトコル学習のコツ @calloc134 12
13. 最初から実務の構成で理解しようとすると、混乱する OAuth の素直な例 → リソースに対する認可 例: Googleフォトに保存している写真を、印刷サービスに渡す OIDC の素直な例 → 外部サービスのユーザ情報を用いたログイン(ID連携) 例: Googleアカウントで別サービスにログインする 想定するアプリは Rails のような サーバ上で動作する Web アプリケーション が良い フロントエンドがなく、Confidential Clientとなり OAuth/OIDC の本質に集中 できる ひねくれてない例から理解する (1) @calloc134 13
14. IdP + SPA + バックエンドAPI のような例をいきなり理解しようとしないこと この構成だと、以下のような点が初学者を混乱させる そもそもOAuthの不適切な用法とも言える。 OAuth を理解するための取っ掛かりとしておすすめできない ひねくれてない例から理解する (2) OAuth/OIDC の違い Public Client アクセストークンの形式 (opaque / JWT) アクセストークンの用法 PKCEの理解 @calloc134 14
15. 一から学習するのにおすすめのルート (もちろん復習にもおすすめ) 学習のルートを工夫する (1) OAuth の登場人物を理解する 1 OAuth の素直な例を理解する 2 ここで考えないこと 認可コードフロー以外のフロー Confidential以外のクライアント どういう攻撃があるのかを理解(一周目) 3 認可リクエスト側 トークンリクエスト側 ここでPKCEがようやく登場 @calloc134 15
16. このルートなら、循環参照が比較的発生せず、つまづきにくい 学習のルートを工夫する (2) クライアントタイプの違いを理解する 4 Confidential / Public Publicに対する攻撃を理解する(二周目) 5 認可コードフロー以外のフローを理解する 6 Implicit Flow ここでようやく、非推奨の理由が理解できる OIDC に進む 7 アクセストークンとIDトークンの用途の違い JWTに関する仕様 後は OAuth と同じように認可コードフローを辿る @calloc134 16
17. 「仕様の表面だけなぞっている」という感覚は、無意識のわからないを潰せず放置している ことから来る 無意識のわからないを潰せていないと 分からないは徹底的に潰すが吉！ このプロセスを通して 「雰囲気で理解している」という不安が解消される (はず) わからないは徹底的に潰す 仕様の意図を言葉で説明できない 実装が仕様からズレていても違和感に気付けない 例: AIの回答を疑いづらい 攻撃者が狙いたくなるポイントを見落としてしまう @calloc134 17
18. 無意識のわからないからくる違和感を 「モヤモヤ」 と呼んでいく まずモヤモヤを質問の形に変換して吐き出せるかどうか が、わからないを潰す上で重要なポイント 例: 「認可コードフローってなんかややこしくない…？」 モヤモヤ… → 「モヤモヤ」から質問をうまく言語化できた この作業は難しいので、繰り返して慣れるしかないかも… まず「モヤモヤを吐き出す」をうまくなる なんでモヤモヤするんだろう？ 1 登場人物が多いから？それとも矢印が多く見えるから？ 2 なんでこの矢印が多いんだろう？ 3 認可コードが挟まってるからかな？ 4 「アクセストークンをそのまま返せばよいのでは？」 5 @calloc134 18
19. おすすめ: GPT 5.5 Extended Thinking の Web検索 個人的な感触だと ChatGPT Plus を契約して質問しまくるのが一番確実 質問の答えだけでなく、「モヤモヤを言語化する」というプロセス自体の練習になる AIの回答は鵜呑みにしすぎないこと！ 必要に応じて仕様で裏取りすること はやはり重要 わからないの潰し方(1): とりあえずAIに質問する @calloc134 19
20. AIに質問した後で裏取りをする段階で、仕様や書籍が確かな情報源となる 一番良いのは仕様を読むこと 。でもしんどかったら書籍で裏取りするだけでも良い と思う(個人的意見) おすすめ書籍 この3つでとりあえず大丈夫！ ritouさんの監修付きで安心！ わからないの潰し方(2): 仕様や書籍で裏取りする Auth屋さんのシリーズ 雰囲気OAuth本 OAuth/OAuth認証/OIDCの違い本 OAuth/OIDCへの攻撃と対策本 @calloc134 20
21. TwitterでOAuth/OIDCのツイートをすればマサカリが来る ！ 一旦わからないことを全部Twitterに放流するのもアリ マサカリの数だけ強くなれる！！ 一つひとつわからないところを潰していけばオッケー わからないの潰し方(3): マサカリを受ける！！ @calloc134 21
22. このセクションのまとめ 学習のコツ ひねくれてない例 から理解する 学習のルート を工夫する わからないを潰す重要性 「モヤモヤを質問にして吐き出す 」をうまくなる 吐き出した後の、わからないの潰し方 とりあえずAIに質問 する 仕様や書籍で裏取り する Twitterでマサカリを受ける (!) @calloc134 22
23. S E C T I O N / 0 3 仕様をもとに読み解く リアルワールド実装 @calloc134 23
24. Hono という サーバサイドTypeScriptフレームワークの OAuth/OIDC に関連のあるミドルウェア実装を例にセキュリティを読み解く。 ここから先の話は仕様を理解していることが前提となるので、 勉強中の人は「仕様を理解しているとわかるんだな」と思ってもらえれば良い ※ Hono: JavaScript上で動作するサーバサイド TypeScriptフレームワーク Express.js のような立ち位置だが、よりモダンな設計思想を取り入れており近年人気が高まっている 前提 @calloc134 24
25. Hono JWK Middlewareにおいて CVE-2026-22818 として報告された脆弱性 alg パラメータのない JWK が存在した場合 ユーザがJWTの alg を指定でき、任意のJWTを偽造できてしまう という脆弱性 ※ 実際は WebCrypto の importKey() がエラーで落ちるので悪用は確認されず (1) Hono JWK Middleware の脆弱性 @calloc134 25
26. 根本原因は、ユーザから渡される JWT の alg を信頼してしまっていたこと → alg にホワイトリスト形式を採用し、フィルタリングを行うことで解決 JWTの alg は、実はユーザが指定できるパラメータ 扱い 外界からの入力 であり、信頼してはいけない しかしこの感覚は、仕様の意図まで深く理解していないとなかなか気づけない難しい部分 JWK Middleware の脆弱性の原因 alg を見てアルゴリズムを決定 1 この時点では署名検証は行われていない ユーザが指定したアルゴリズムで署名検証を行う 2 @calloc134 26
27. フレームワーク側の脆弱性ではないが、OAuth/OIDC の深い理解が必要 な設定ミス問題 IdP + SPA + バックエンドAPIの構成で、 バックエンドAPIがJWTのaudを検証していない場合、異なるAPIへのJWTでもAPIアクセスが出来てしまう という問題 (攻撃者が作成した別アプリ用のJWTでも受け入れるため、攻撃者のアプリにログインしたユーザになりすますことが 出来る) ※ 実際は多くのIdPでテナント分離されているので一定の保護はされるが 同一テナントの場合は危険 (2) Hono JWT Middleware の設定ミスによる問題 @calloc134 27
28. JWT Middlewareの設定に aud の検証を行うオプションを忘れると発生 → JWTで aud を検証していなければ 攻撃者の作成した別アプリAPI用のJWTでも受け入れてしまう ことに JWT Middleware の設定ミスの原因 aud : JWT形式のアクセストークンにおいて、どのリソースサーバ向けのトークンかを示すパラメータ IdP + SPA + バックエンドAPIの構成では バックエンドAPI = リソースサーバ つまり aud = バックエンドAPIの識別子である必要がある @calloc134 28
29. そもそも IdP + SPA + バックエンドAPIの構成で、アクセストークンをセッション代わりに使うのは 良くない そもそもこの構成は良くない 慎重に扱わないと今回のように JWT検証の設定ミスによる脆弱性 が発生する SPAがOAuthクライアントとして動作するため、Public Client 扱い しかし OAuthでは出来るだけ Confidential Client を使うことを推奨 この用法は「APIリソースを認可する」というより 「外部のアカウント情報を連携してバックエンドAPIにログインする」ためにOAuthを利用している この用途ならそもそもID連携用に作られた OIDC の IDトークンを使う方が適切 @calloc134 29
30. より良い解決策: バックエンド側APIで OIDC の IDトークンを検証しログイン実装 SPA と APIの通信は アクセストークンではなく httpOnlyなセッションCookie を使う ※ 余談: セッションCookieを利用するため、CSRF対策は必須 じゃあどうすべき？ 認可のためのOAuthではなく ID連携のためのOIDCを使う → より意図に沿った選択 Public Client ではなく Confidential Client を使う → より安全な構成 SPAとAPIの通信はアクセストークンではなく httpOnlyなセッションCookie を使う → 悪性なスクリプトからのアクセスを防ぐ (副次的効果) @calloc134 30
31. このセクションのまとめ 仕様を深くまで理解していると、違和感に素早く気づける JWK Middleware の脆弱性 仕様を深くまで理解していると、より優れた解決策を選択できる JWT Middleware の設定ミスによる問題 OAuthではなくOIDCを選択することで、より安全な構成にできる @calloc134 31
32. S E C T I O N / 0 4 まとめ @calloc134 32
33. 本スライドのまとめ 学習を進める上でのコツ 1 ひねくれてない例から理解するべし 学習のルートを工夫するべし わからないは徹底的に潰すべし 仕様を腹落ちさせることで 2 違和感に素早く気づける より優れた解決策を選択できる @calloc134 33
34. そんな本を執筆しています！ イラストもふんだんに使い、 視覚的・直感的に 理解できるように工夫しています。 全セクション無料なので、是非読んでみてください！ デジタルブックの宣伝 ひねくれてない例から 学習のルートを最大限工夫して わからないを徹底的に潰してくれる @calloc134 34
35. Thank you! Thank you! Thank you! @calloc134 // ID 沼入門