OAuth 2.1 + PKCEのススメ ～Spotify APIを通して理解する、OAuth 2.1 + PKCEの基礎と実践～

Transcript

1. OAuth 2.1 + PKCEのススメ 〜Spotify APIを通して理解する、OAuth 2.1 + PKCEの基礎と実践〜 合同会社DMM.com プラットフォーム開発本部 なずな (@na2na_chang) 1
2. ⾃⼰紹介 なずな(@na2na_chang) ➢ 合同会社DMM.com(2024年新卒) ◦ プラットフォーム開発本部 マイクロサービスアーキテクトグループ 認可チーム ➢ 認可プロダクトをリプレースするお仕事 ◦ PHP → Go ◦ MySQL → TiDB Cloud ◦ オンプレ → GKE ➢ DMMに⼊る前に業務委託でフロントエンドやインフラのお仕事 2
3. プラットフォーム開発本部 プラットフォーム開発本部は、DMMの各サービスで共通に利⽤される基盤を開発している部署 例: 会員管理、認証や認可、決済、DMMポイント等 DMMの各種サービスは、プラットフォーム開発本部がAPIの形で提供している機能を利⽤して作られている つまり、基盤に不具合が発⽣するとDMMの多くのサービスに直接影響し、 停⽌させる可能性のある⾮常に重要な基盤を扱っている 3
4. 認可チームはそんな部署の中のチームの⼀つ 4
5. 認可チーム OpenID Connect (OIDC) に準拠した認可サーバを提供 → 作る側に回る以上、オープン‧スタンダードの理解はしておきたい → OIDC は、OAuth2に基づいて構築された ID プロトコルおよびオープン‧スタンダード →まずはOAuth2から始めよう. 5
6. OAuth2について知る （前のスライドの続き） →その技術について知るには、実際にその技術を使ったものを作るのが⼀番早い →⾃⾝もよく使うSpotifyを題材にしたい →ドキュメントを読むとSPAではAuthorization Code With PKCE Flowを推奨されている →調べて実装までやってみた（今⽇はここの成果） In scenarios where storing the client secret is not safe (e.g. desktop, mobile apps or JavaScript web apps running in the browser), you can use the authorization code with PKCE, as it provides protection against attacks where the authorization code may be intercepted. 引⽤元: https://developer.spotify.com/documentation/web-api/concepts/authorization 6
7. 今⽇話すこと 1. OAuth2.0の概要 2. OAuth2.1での更新点 3. Authorization Code With PKCE Flowの概要と採⽤モチベーション 4. Authorization Code With PKCE Flowを、Spotify WebAPIを題材に追ってみる 7
8. 今⽇のゴール • OAuth2.1についてなんとなくわかった気持ちになる • Authorization Code With PKCE Flowを使うメリットがわかって、使ってみようかな？という気 持ちになる 8
9. 認可の例（Implicit Grant Flowの場合） 自作Spotify Webアプリ なずなさん Spotifyのサーバ Spotifyの 認可サーバ ①プレイリストの一覧を 参照する許可をください 9 リソースオーナー クライアント 認可サーバ リソースサーバ ②なずなさんの許可 ③なずなさんの許可 ④Spotifyのリソースを 操作するためのアクセストークン ⑤アクセストークン ⑥なずなさんの Spotifyのプレイリスト情報
10. 認可の例（Implicit Grant Flowの場合） 自作Spotify Webアプリ なずなさん Spotifyのサーバ Spotifyの 認可サーバ ①プレイリストの一覧を 参照する許可をください 10 リソースオーナー クライアント 認可サーバ リソースサーバ ②なずなさんの許可 ③なずなさんの許可 ④Spotifyのリソースを 操作するためのアクセストークン ⑤アクセストークン ⑥なずなさんの Spotifyのプレイリスト情報
11. 認可の例（Implicit Grant Flowの場合） 自作Spotify Webアプリ なずなさん Spotifyのサーバ Spotifyの 認可サーバ ①プレイリストの一覧を 参照する許可をください 11 リソースオーナー クライアント 認可サーバ リソースサーバ ②なずなさんの許可 ③なずなさんの許可 ④Spotifyのリソースを 操作するためのアクセストークン ⑤アクセストークン ⑥なずなさんの Spotifyのプレイリスト情報
12. 認可の例（Implicit Grant Flowの場合） 自作Spotify Webアプリ なずなさん Spotifyのサーバ Spotifyの 認可サーバ ①プレイリストの一覧を 参照する許可をください 12 リソースオーナー クライアント 認可サーバ リソースサーバ ②なずなさんの許可 ③なずなさんの許可 ④Spotifyのリソースを 操作するためのアクセストークン ⑤アクセストークン ⑥なずなさんの Spotifyのプレイリスト情報
13. 認可の例（Implicit Grant Flowの場合） 自作Spotify Webアプリ なずなさん Spotifyのサーバ Spotifyの 認可サーバ ①プレイリストの一覧を 参照する許可をください 13 リソースオーナー クライアント 認可サーバ リソースサーバ ②なずなさんの許可 ③なずなさんの許可 ④Spotifyのリソースを 操作するためのアクセストークン ⑤アクセストークン ⑥なずなさんの Spotifyのプレイリスト情報
14. OAuth 2.0の概要 OAuth 2.0とは、IETF OAuth WGで仕様策定されている標準仕様群です。 ウェブサイトまたはアプリケーションが、ユーザーに代わって他のウェブアプリがホストしているリソース に、アクセスできるよう設計された基準です。 2012年に OAuth 1.0 の後を継ぎ、現在、事実上、オンライン認可の業界標準となっています。OAuth 2.0 は、 ユーザーの認証情報を共有しなくても、ユーザーに代わって、合意されたアクセスを提供し、クライアントア プリがリソースに対して実⾏できるアクションを規制します。 OAuth 2.0 は、認可プロトコルであり、認証プロトコルではありません。 引⽤元: https://auth0.com/jp/intro-to-iam/what-is-oauth-2 14
15. OAuth 2.0の概要 簡単に⾔うと‧‧‧ • アプリケーションが、 • ユーザーに代わって • データの取得ができるようにする許可を 安全に受け渡しするためのお約束です。 15
16. OAuth 2.1の概要 OAuth2.0からの⼤きな変更は、以下です。 • Authorization Code Grant FlowにおけるPKCE の必須化 • リダイレクト URI の厳密な⼀致 • Implicit Grant Flow(response_type=token)の廃⽌ • Resource Owner Password Credentials Grant の廃⽌ • Bearer トークンを URI のクエリ⽂字列に含めることの禁⽌ • パブリッククライアントのリフレッシュトークンの制限 • クレデンシャルの有無によりクライアントの定義の簡素化 参考: https://oauth.net/2.1/ 16
17. OAuth 2.1の概要 OAuth2.1は、現在進⾏形でIETF OAuth WGで仕様策定が進んでいる標準仕様群です。 OAuth 2.1 ドラフト仕様の作成者の 1 ⼈が以下のように述べているように、新仕様が増えるというよりかは 既に存在していた既存仕様やその拡張仕様を1つに集約したものです。 That also means specifically that this effort will not define any new behavior itself, it is just to capture behavior defined in other specs. 引⽤元: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1 17
18. OAuth2.0からの⼤きな変更は、以下です。 • Authorization Code FlowにおけるPKCE の必須化 • リダイレクト URI の厳密な⼀致 • Implicit Grant Flow(response_type=token)の廃⽌ • Resource Owner Password Credentials Grant の廃⽌ • Bearer トークンを URI のクエリ⽂字列に含めることの禁⽌ • パブリッククライアントのリフレッシュトークンの制限 • クレデンシャルの有無によりクライアントの定義の簡素化 参考: https://oauth.net/2.1/ OAuth 2.1の概要 18
19. そもそもPKCEとは？ PKCE（Proof Key for Code Exchange）とは、認可コード横取り攻撃への対策を⽬的とし、RFC7636 で定義されているOAuth2.0拡張仕様です。 PKCEの機構を持たないOAuth2.0の認可フローでは、悪意のあるアプリが何らかの⽅法で認可コード を含むカスタムURIを取得した場合、ユーザー固有のアクセストークンを横取りされる恐れがありま す。 引⽤元: https://developers.line.biz/ja/docs/line-login/integrate-pkce/ 19
20. Authorization Code With PKCE Flowの概要 OAuth 2.0のAuthorization Code FlowにPKCE (Proof Key for Code Exchange) を組み込むことでセ キュリティの強化をしよう、という仕様です。 特にクライアントシークレットを持たないパブリッククライアント向けに設計されており、不正な認 可コードの利⽤を防ぎます。 たとえばAuth0ではモバイルでは必須、SPAにおいては推奨とされています。 20
21. 通常のAuthorization Code Grant Flow 21
22. Authorization Code With PKCE Flowの概要 通常の認可コードフローから以下が追加されています。 • 認可コード取得時に以下のパラメータを追加 ◦ code_challenge ◦ code_challenge_method • 認可コードとアクセストークンの交換時に以下のパラメータを追加 ◦ code_verifier 22
23. Authorization Code With PKCE Flowの概要 23
24. Authorization Code With PKCE Flowの概要 認可サーバが code_verifierを使って検証 24
25. SPAにおける採⽤モチベーション 以下の攻撃の対策として利⽤できます。 • CSRF攻撃 • 認可コード横取り攻撃 • （XSSとの合わせ技で）認可コードインジェクション攻撃 • （XSSとの合わせ技で）認可コードの盗難 などが挙げられます。 25
26. SPAにおける採⽤モチベーション 26
27. SPAにおける採⽤モチベーション 27 正規のアプリも悪意あるアプリも com.example.app://oauth-callback のようなリダイレクト URIが設定されている
28. SPAにおける採⽤モチベーション code_challengeの検証に 失敗しエラーとなる 28
29. 認可フローを、Spotify WebAPIを題材に追ってみる ⼤まかにどういった処理やステップがあるかに焦点を当てて、 特にPKCEに関わるところに限り紹介します。 今回のコードは以下のリポジトリで公開しています。 https://github.com/na2na-p/BreezifyArranger 29
30. 認可フローを、Spotify WebAPIを題材に追ってみる 注意！ • 例⽰のコード通りに実装して損害が⽣じた場合でも責任は取れません。 30
31. 今回の構成 今回は最低限の動作紹介ができればいいため、私の慣れたスタックを使います。 フロントエンド: React + TypeScript + react-router-dom ※API利⽤やOAuth 2スコープ定数の利⽤のために@spotify/web-api-ts-sdkも⼀部利⽤します。 31
32. 必要になるルート 32
33. 必要になるルート 33
34. 認可コードのリクエスト 本アプリケーションにおいて、 Authorizaiton Code Flowを開始するためのボタンがあるだけになっています。 34
35. 認可コードのリクエスト 1. code_verifierの⽣成 2. code_challengeの⽣成 3. Stateの⽣成 4. Spotifyに渡すためのパラメータ組み⽴て 5. Spotifyの認可付与画⾯へのリダイレクト 35
36. 認可コードのリクエスト 36
37. 今回は128⽂字のランダム⽂字列を⽣成します。 認可コードとトークンの交換の際に必要になる ため、永続化します。 code_verifierの⽣成 37
38. code_verifierの⽣成 今回の場合、 ⼀度⾃サイトから離れてSpotifyに遷移するため、 useStateのようなオンメモリ管理では揮発してしまう → ブラウザ内で永続化できる場所に配置する 38
39. 先ほど⽣成したcode_verifierをハッシュ化して code_challengeを⽣成します。 code_challngeの⽣成 39
40. パラメータの⽤意 最後にSpotifyに渡すためのパラメータを⽤意し ます。 注⽬すべき点は、 • code_challenge_method • code_challenge です。 40
41. リソースオーナーによる認可 パラメータが正しく設定されていればこのよう になります。 41
42. リソースオーナーによる認可 42
43. 認可コードレスポンスの検証 リダイレクト時には右のようなパラメータが付 与されて返されます。 http://localhost:5173/auth/spotify-oauth2-call back/? code=(認可コード) state=(リクエスト時に付与したState) 以下はエラー時に付与されます。 error=(エラー内容) 43
44. 認可コードレスポンスの検証 初回のレンダリングで⾏うため、useEffectを利 ⽤します。 検証に失敗した場合はクリーンアップ関数を利 ⽤してローカルストレージの初期化をします。 値検証は時間の都合で割愛します 44
45. Tokenのリクエスト ここまでで得られた値を使ってTokenのリクエス トをします。 45
46. Tokenのリクエスト 46
47. Tokenのリクエスト 認可コード取得のために⽣成したcode_verifierをこ こでリクエストボディに付与します。 以下の2値を認可サーバが検証します。 • code_verifierを、認可コードリクエストの時 に指定したcode_challnege_methodでハッ シュ化した値 • 認可コードリクエストの時に指定した code_challnegeの値 47
48. Tokenのリクエスト Tokenリクエストに成功したら晴れてリソース オーナーの持つリソースにアクセスできるよう になります。 48
49. おまけ ここまで、Authorization Code With PKCE Flowのいわば正常系にあたるものを紹介しました。 最後に、実際に悪意あるクライアントに認可コードを盗られたと仮定して、PKCE検証にFailすると、 認可サーバからどういったレスポンスが帰ってくるかを⾒てみようと思います。 49
50. PKCEにFailする様⼦を観察する code_challengeの検証に 失敗しエラーとなる 50
51. PKCEにFailする様⼦を観察する 51
52. 最後に • Authorization Code With PKCE Flowの活⽤ ◦ PKCEを利⽤することでよりセキュアな認可フローの実装ができるようになります • 今回はOAuthクライアントの振る舞いを実装を通じて学習できた ◦ 次は認可サーバの実装をしてみたい ◦ たとえば⾃宅のインフラに認証‧認可基盤を作って適⽤してみるとか 52
53. 53 みなさんも PKCEを使ってみましょう！