SSRアプリケーションにおけるPKCE付き認可コードフロー

Transcript

1. SSR アプリケーションにおける PKCE 付き認可コードフロー
2. 認可コードフロー RFC 6749 The OAuth 2.0 Authorization Framework で定義される認可フローの一つ クライアントアプリケーションがユーザーの代わりにリソースサーバーにアクセスする権限を取得 アクセストークンの直接的な露出を防ぐ OAuth 2.0 で最も安全かつ標準的とされる認可フロー Authorization Code Grant
3. 認可コードフローの流れ Resource Server Auth Server Client User-Agent Resource Owner Resource Server Auth Server Client User-Agent Resource Owner (A) アクセス要求 (B) 認可エンドポイントへリダイレクト (C) 認証要求 (C) 認証情報・認可 (D) 認可コード付きリダイレクト (E) トークン要求 ( 認可コード + クライアント認証) (F) トークン応答 ( アクセストークン等) (G) アクセストークンでAPI 呼び出し (H) 保護されたリソース
4. PKCE 付き認可コードフローとは RFC 7636 Proof Key for Code Exchange by OAuth Public Clients で定義される認可コードフロー の拡張 パブリッククライアント（SPA やモバイルアプリ）向けのセキュリティ強化 認可コード横取り攻撃を防ぐ クライアントシークレットが安全に保管できない環境でも使用可能 動的に生成されるcode_verifier とcode_challenge を使用 Authorization Code Grant with Proof Key for Code Exchange
5. PKCE 付き認可コードフローの流れ Resource Server Auth Server Client User-Agent Resource Owner Resource Server Auth Server Client User-Agent Resource Owner (A) アクセス要求 (B) code_verifier/challenge 生成 (C) 認可エンドポイントへリダイレクト (+ code_challenge) code_challenge 保存 (D) 認証要求 (D) 認証情報・認可 (E) 認可コード付きリダイレクト (F) トークン要求 ( 認可コード + code_verifier) (G) code_verifier 検証 (H) トークン応答 ( アクセストークン等) (I) アクセストークンでAPI 呼び出し (J) 保護されたリソース
6. SSR でもPKCE を使うべき理由 OAuth 2.1 (draft) - すべてのクライアントでPKCE を必須化 コンフィデンシャルクライアント（SSR 含む）でも必須 認可コード横取り攻撃への包括的な対策 RFC 9700 - OAuth 2.0 セキュリティ現行ベストプラクティス PKCE をすべての認可コードフローで推奨 クライアントタイプに関わらず実装すべき SSR アプリケーションでの利点 エッジ環境でのシークレット管理リスクを軽減 将来的な標準への準拠 統一的なセキュリティモデルの採用 RFC 9700 とOAuth 2.1 が示す新しいセキュリティ基準
7. 主要認証ライブラリのPKCE サポート状況 ライブラリ PKCE サポート 備考 Auth.js (NextAuth.js) ✅ OAuth 2.0 プロバイダーでchecks パラメータをサポート Better Auth ✅ 完全対応、SSR 考慮済み、state とPKCE をDB に保存 Supabase Auth ✅ SSR ではデフォルトでPKCE 、@supabase/ssr パッケージ提供 Firebase Auth ❌ 2022 年から機能リクエスト中、Implicit フローのみ Auth0 ✅ Mobile/SPA SDK で完全サポート、推奨実装 Clerk ✅ OAuth 2.1 準拠、すべての認可コードフローでPKCE 必須
8. 主要IdP のPKCE サポート状況 プロバイダー PKCE サポート 備考 Google ✅ 対応、SPA でもクライアントシークレットを要求 Microsoft ✅ 対応、SPA では必須 GitHub ❌ 未対応、コミュニティから要望多数 Apple ❌ 未対応