Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Ossamoon Ossamoon
June 23, 2025
46

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

Avatar for Ossamoon

Ossamoon

June 23, 2025
Tweet

Transcript

  1. 認可コードフローの流れ 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) 保護されたリソース
  2. 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
  3. 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) 保護されたリソース
  4. SSR でもPKCE を使うべき理由 OAuth 2.1 (draft) - すべてのクライアントでPKCE を必須化 コンフィデンシャルクライアント(SSR

    含む)でも必須 認可コード横取り攻撃への包括的な対策 RFC 9700 - OAuth 2.0 セキュリティ現行ベストプラクティス PKCE をすべての認可コードフローで推奨 クライアントタイプに関わらず実装すべき SSR アプリケーションでの利点 エッジ環境でのシークレット管理リスクを軽減 将来的な標準への準拠 統一的なセキュリティモデルの採用 RFC 9700 とOAuth 2.1 が示す新しいセキュリティ基準
  5. 主要認証ライブラリの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 必須
  6. 主要IdP のPKCE サポート状況 プロバイダー PKCE サポート 備考 Google ✅ 対応、SPA

    でもクライアントシークレットを要求 Microsoft ✅ 対応、SPA では必須 GitHub ❌ 未対応、コミュニティから要望多数 Apple ❌ 未対応