OAuth 2.0 授權碼流程

Vibe Prompt

「幫我實作 OAuth 2.0 Authorization Code + PKCE Flow，用 Supabase 做 Identity Provider。」

流程

1. 前端 → Supabase: 跳轉到授權頁面
   GET https://<project>.supabase.co/auth/v1/authorize
     ?client_id=<client_id>
     &redirect_uri=<redirect_uri>
     &response_type=code
     &code_challenge=<SHA256(code_verifier)>
     &code_challenge_method=S256
     &scope=openid profile email

2. 使用者登入並授權

3. Supabase → 前端: 跳轉回 redirect_uri 帶授權碼
   https://myapp.com/auth/callback?code=<auth_code>

4. 前端 → 後端: 傳授權碼

5. 後端 → Supabase: 換取 Token
   POST https://<project>.supabase.co/auth/v1/token
     ?grant_type=authorization_code
     &code=<auth_code>
     &code_verifier=<original_code_verifier>
     &redirect_uri=<redirect_uri>

6. Supabase → 後端: access_token + refresh_token + id_token

7. 後端 → 前端: 設定 Session Cookie

Next.js API Route

// app/api/auth/callback/route.ts
import { createClient } from '@/utils/supabase/server'
import { NextResponse } from 'next/server'

export async function GET(request: Request) {
  const { searchParams, origin } = new URL(request.url)
  const code = searchParams.get('code')
  const next = searchParams.get('next') ?? '/'
  
  if (code) {
    const supabase = createClient()
    const { error } = await supabase.auth.exchangeCodeForSession(code)
    if (!error) {
      return NextResponse.redirect(`${origin}${next}`)
    }
  }
  
  return NextResponse.redirect(`${origin}/auth-error`)
}

PKCE 好處

✅ 授權碼在傳輸中被攔截也無法使用（需要 code_verifier）
✅ 不需要 client_secret（適合 SPA）
✅ 防止授權碼攔截攻擊

關鍵要點

✅ 請根據本章主題補充具體的學習重點
✅ 建議加入比較表格、程式碼範例或流程圖
✅ 確保內容扎實且有價值

PKCE 流程說明

PKCE (Proof Key for Code Exchange) 是為了解決 SPA 和手機 App 無法安全儲存 Client Secret 而設計的。

完整流程

1. 前端產生 Code Verifier (43-128 字元的亂數字串)
2. 前端計算 Code Challenge = SHA256(Code Verifier)
3. 前端請求授權碼時帶上 Code Challenge
4. 授權伺服器記錄 Code Challenge，回傳授權碼
5. 前端用授權碼 + Code Verifier 交換 Token
6. 授權伺服器驗證 SHA256(Verifier) == Challenge
7. 驗證通過才發放 Token

Code Verifier 產生方式

// 前端 JavaScript 產生 Code Verifier
function generateCodeVerifier() {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64URLEncode(array);
}

async function generateCodeChallenge(verifier) {
  const hash = await crypto.subtle.digest("SHA-256", 
    new TextEncoder().encode(verifier));
  return base64URLEncode(new Uint8Array(hash));
}

function base64URLEncode(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/, "");
}

S256 vs Plain

| 模式 | 說明 | 安全性 | |:----:|------|:------:| | S256 | SHA-256 雜湊 Code Verifier | 高（即使 Code Challenge 被攔截也無法逆推） | | plain | 直接傳送 Code Verifier | 低（攔截到等於直接拿到） |

強烈建議使用 S256。plain 模式只是為了相容舊系統。

PKCE：為什麼 SPA 和 App 需要不同的授權流程？

傳統的 Authorization Code Flow 需要在後端安全地儲存一個 Client Secret。但 SPA（React、Vue）和手機 App 的原始碼是可以被使用者查看的——裡面的 Secret 等於是公開的。

PKCE（讀作「pixie」）解決了這個問題：

實際案例：React SPA + LINE Login

// React 前端直接產生 Code Verifier 與 Challenge
const generatePKCE = async () => {
  const verifier = Array.from({ length: 64 }, () => 
    'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~'
      [Math.floor(Math.random() * 66)]
  ).join('');
  
  sessionStorage.setItem('code_verifier', verifier);
  
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const hash = await crypto.subtle.digest('SHA-256', data);
  
  const challenge = btoa(String.fromCharCode(...new Uint8Array(hash)))
    .replace(/=/g, '').replace(/\+/g, '-').replace(/\//g, '_');
  
  // 導向 LINE 登入頁
  window.location.href = `https://access.line.me/oauth2/v2.1/authorize?
    response_type=code&
    client_id=${LINE_CLIENT_ID}&
    redirect_uri=${encodeURIComponent(window.location.origin + '/callback')}&
    state=${crypto.randomUUID()}&
    code_challenge=${challenge}&
    code_challenge_method=S256`;
};

下一章預告：整合所有授權知識

從 IAM 基礎到 RBAC/ABAC，從 Session 管理到 OAuth PKCE——下一章將整合所有知識，建立一個從認證到授權的完整系統。