Slide 1
Slide 1 text
OAuth 2.1 + PKCEのススメ
〜Spotify APIを通して理解する、OAuth 2.1 + PKCEの基礎と実践〜
合同会社DMM.com
プラットフォーム開発本部
なずな (@na2na_chang)
1
Slide 2
Slide 2 text
⾃⼰紹介
なずな(@na2na_chang)
➢ 合同会社DMM.com(2024年新卒)
○ プラットフォーム開発本部
マイクロサービスアーキテクトグループ
認可チーム
➢ 認可プロダクトをリプレースするお仕事
○ PHP → Go
○ MySQL → TiDB Cloud
○ オンプレ → GKE
➢ DMMに⼊る前に業務委託でフロントエンドやインフラのお仕事
2
Slide 3
Slide 3 text
プラットフォーム開発本部
プラットフォーム開発本部は、DMMの各サービスで共通に利⽤される基盤を開発している部署
例: 会員管理、認証や認可、決済、DMMポイント等
DMMの各種サービスは、プラットフォーム開発本部がAPIの形で提供している機能を利⽤して作られている
つまり、基盤に不具合が発⽣するとDMMの多くのサービスに直接影響し、
停⽌させる可能性のある⾮常に重要な基盤を扱っている
3
Slide 4
Slide 4 text
認可チームはそんな部署の中のチームの⼀つ
4
Slide 5
Slide 5 text
認可チーム
OpenID Connect (OIDC) に準拠した認可サーバを提供
→ 作る側に回る以上、オープン‧スタンダードの理解はしておきたい
→ OIDC は、OAuth2に基づいて構築された ID プロトコルおよびオープン‧スタンダード
→まずはOAuth2から始めよう.
5
Slide 6
Slide 6 text
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
Slide 7
Slide 7 text
今⽇話すこと
1. OAuth2.0の概要
2. OAuth2.1での更新点
3. Authorization Code With PKCE Flowの概要と採⽤モチベーション
4. Authorization Code With PKCE Flowを、Spotify WebAPIを題材に追ってみる
7
Slide 8
Slide 8 text
今⽇のゴール
● OAuth2.1についてなんとなくわかった気持ちになる
● Authorization Code With PKCE Flowを使うメリットがわかって、使ってみようかな？という気
持ちになる
8
Slide 9
Slide 9 text
認可の例（Implicit Grant Flowの場合）
自作Spotify
Webアプリ
なずなさん
Spotifyのサーバ
Spotifyの
認可サーバ
①プレイリストの一覧を
参照する許可をください
9
リソースオーナー
クライアント 認可サーバ
リソースサーバ
②なずなさんの許可
③なずなさんの許可
④Spotifyのリソースを
操作するためのアクセストークン
⑤アクセストークン
⑥なずなさんの
Spotifyのプレイリスト情報
Slide 10
Slide 10 text
認可の例（Implicit Grant Flowの場合）
自作Spotify
Webアプリ
なずなさん
Spotifyのサーバ
Spotifyの
認可サーバ
①プレイリストの一覧を
参照する許可をください
10
リソースオーナー
クライアント 認可サーバ
リソースサーバ
②なずなさんの許可
③なずなさんの許可
④Spotifyのリソースを
操作するためのアクセストークン
⑤アクセストークン
⑥なずなさんの
Spotifyのプレイリスト情報
Slide 11
Slide 11 text
認可の例（Implicit Grant Flowの場合）
自作Spotify
Webアプリ
なずなさん
Spotifyのサーバ
Spotifyの
認可サーバ
①プレイリストの一覧を
参照する許可をください
11
リソースオーナー
クライアント 認可サーバ
リソースサーバ
②なずなさんの許可
③なずなさんの許可
④Spotifyのリソースを
操作するためのアクセストークン
⑤アクセストークン
⑥なずなさんの
Spotifyのプレイリスト情報
Slide 12
Slide 12 text
認可の例（Implicit Grant Flowの場合）
自作Spotify
Webアプリ
なずなさん
Spotifyのサーバ
Spotifyの
認可サーバ
①プレイリストの一覧を
参照する許可をください
12
リソースオーナー
クライアント 認可サーバ
リソースサーバ
②なずなさんの許可
③なずなさんの許可
④Spotifyのリソースを
操作するためのアクセストークン
⑤アクセストークン
⑥なずなさんの
Spotifyのプレイリスト情報
Slide 13
Slide 13 text
認可の例（Implicit Grant Flowの場合）
自作Spotify
Webアプリ
なずなさん
Spotifyのサーバ
Spotifyの
認可サーバ
①プレイリストの一覧を
参照する許可をください
13
リソースオーナー
クライアント 認可サーバ
リソースサーバ
②なずなさんの許可
③なずなさんの許可
④Spotifyのリソースを
操作するためのアクセストークン
⑤アクセストークン
⑥なずなさんの
Spotifyのプレイリスト情報
Slide 14
Slide 14 text
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
Slide 15
Slide 15 text
OAuth 2.0の概要
簡単に⾔うと‧‧‧
● アプリケーションが、
● ユーザーに代わって
● データの取得ができるようにする許可を
安全に受け渡しするためのお約束です。
15
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
そもそも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
Slide 20
Slide 20 text
Authorization Code With PKCE Flowの概要
OAuth 2.0のAuthorization Code FlowにPKCE (Proof Key for Code Exchange) を組み込むことでセ
キュリティの強化をしよう、という仕様です。
特にクライアントシークレットを持たないパブリッククライアント向けに設計されており、不正な認
可コードの利⽤を防ぎます。
たとえばAuth0ではモバイルでは必須、SPAにおいては推奨とされています。
20
Slide 21
Slide 21 text
通常のAuthorization Code Grant Flow
21
Slide 22
Slide 22 text
Authorization Code With PKCE Flowの概要
通常の認可コードフローから以下が追加されています。
● 認可コード取得時に以下のパラメータを追加
○ code_challenge
○ code_challenge_method
● 認可コードとアクセストークンの交換時に以下のパラメータを追加
○ code_verifier
22
Slide 23
Slide 23 text
Authorization Code With PKCE Flowの概要
23
Slide 24
Slide 24 text
Authorization Code With PKCE Flowの概要
認可サーバが
code_verifierを使って検証
24
Slide 25
Slide 25 text
SPAにおける採⽤モチベーション
以下の攻撃の対策として利⽤できます。
● CSRF攻撃
● 認可コード横取り攻撃
● （XSSとの合わせ技で）認可コードインジェクション攻撃
● （XSSとの合わせ技で）認可コードの盗難
などが挙げられます。
25
Slide 26
Slide 26 text
SPAにおける採⽤モチベーション
26
Slide 27
Slide 27 text
SPAにおける採⽤モチベーション
27
正規のアプリも悪意あるアプリも
com.example.app://oauth-callback
のようなリダイレクト URIが設定されている
Slide 28
Slide 28 text
SPAにおける採⽤モチベーション
code_challengeの検証に
失敗しエラーとなる
28
Slide 29
Slide 29 text
認可フローを、Spotify WebAPIを題材に追ってみる
⼤まかにどういった処理やステップがあるかに焦点を当てて、
特にPKCEに関わるところに限り紹介します。
今回のコードは以下のリポジトリで公開しています。
https://github.com/na2na-p/BreezifyArranger
29
Slide 30
Slide 30 text
認可フローを、Spotify WebAPIを題材に追ってみる
注意！
● 例⽰のコード通りに実装して損害が⽣じた場合でも責任は取れません。
30
Slide 31
Slide 31 text
今回の構成
今回は最低限の動作紹介ができればいいため、私の慣れたスタックを使います。
フロントエンド: React + TypeScript + react-router-dom
※API利⽤やOAuth 2スコープ定数の利⽤のために@spotify/web-api-ts-sdkも⼀部利⽤します。
31
Slide 32
Slide 32 text
必要になるルート
32
Slide 33
Slide 33 text
必要になるルート
33
Slide 34
Slide 34 text
認可コードのリクエスト
本アプリケーションにおいて、
Authorizaiton Code Flowを開始するためのボタンがあるだけになっています。
34
Slide 35
Slide 35 text
認可コードのリクエスト
1. code_verifierの⽣成
2. code_challengeの⽣成
3. Stateの⽣成
4. Spotifyに渡すためのパラメータ組み⽴て
5. Spotifyの認可付与画⾯へのリダイレクト
35
Slide 36
Slide 36 text
認可コードのリクエスト
36
Slide 37
Slide 37 text
今回は128⽂字のランダム⽂字列を⽣成します。
認可コードとトークンの交換の際に必要になる
ため、永続化します。
code_verifierの⽣成
37
Slide 38
Slide 38 text
code_verifierの⽣成
今回の場合、
⼀度⾃サイトから離れてSpotifyに遷移するため、
useStateのようなオンメモリ管理では揮発してしまう
→ ブラウザ内で永続化できる場所に配置する
38
Slide 39
Slide 39 text
先ほど⽣成したcode_verifierをハッシュ化して
code_challengeを⽣成します。
code_challngeの⽣成
39
Slide 40
Slide 40 text
パラメータの⽤意
最後にSpotifyに渡すためのパラメータを⽤意し
ます。
注⽬すべき点は、
● code_challenge_method
● code_challenge
です。
40
Slide 41
Slide 41 text
リソースオーナーによる認可
パラメータが正しく設定されていればこのよう
になります。
41
Slide 42
Slide 42 text
リソースオーナーによる認可
42
Slide 43
Slide 43 text
認可コードレスポンスの検証
リダイレクト時には右のようなパラメータが付
与されて返されます。
http://localhost:5173/auth/spotify-oauth2-call
back/?
code=(認可コード)
state=(リクエスト時に付与したState)
以下はエラー時に付与されます。
error=(エラー内容)
43
Slide 44
Slide 44 text
認可コードレスポンスの検証
初回のレンダリングで⾏うため、useEffectを利
⽤します。
検証に失敗した場合はクリーンアップ関数を利
⽤してローカルストレージの初期化をします。
値検証は時間の都合で割愛します
44
Slide 45
Slide 45 text
Tokenのリクエスト
ここまでで得られた値を使ってTokenのリクエス
トをします。
45
Slide 46
Slide 46 text
Tokenのリクエスト
46
Slide 47
Slide 47 text
Tokenのリクエスト
認可コード取得のために⽣成したcode_verifierをこ
こでリクエストボディに付与します。
以下の2値を認可サーバが検証します。
● code_verifierを、認可コードリクエストの時
に指定したcode_challnege_methodでハッ
シュ化した値
● 認可コードリクエストの時に指定した
code_challnegeの値
47
Slide 48
Slide 48 text
Tokenのリクエスト
Tokenリクエストに成功したら晴れてリソース
オーナーの持つリソースにアクセスできるよう
になります。
48
Slide 49
Slide 49 text
おまけ
ここまで、Authorization Code With PKCE Flowのいわば正常系にあたるものを紹介しました。
最後に、実際に悪意あるクライアントに認可コードを盗られたと仮定して、PKCE検証にFailすると、
認可サーバからどういったレスポンスが帰ってくるかを⾒てみようと思います。
49
Slide 50
Slide 50 text
PKCEにFailする様⼦を観察する
code_challengeの検証に
失敗しエラーとなる
50
Slide 51
Slide 51 text
PKCEにFailする様⼦を観察する
51
Slide 52
Slide 52 text
最後に
● Authorization Code With PKCE Flowの活⽤
○ PKCEを利⽤することでよりセキュアな認可フローの実装ができるようになります
● 今回はOAuthクライアントの振る舞いを実装を通じて学習できた
○ 次は認可サーバの実装をしてみたい
○ たとえば⾃宅のインフラに認証‧認可基盤を作って適⽤してみるとか
52
Slide 53
Slide 53 text
53
みなさんも PKCEを使ってみましょう！