← 課程地圖

SUPABASE CORE · 115

Auth / Session / JWT / User Context:登入成功之後到底發生什麼?

Authentication 的價值不是畫面顯示「已登入」,而是讓後續 API request 建立可驗證 user context,資料層才能依此做 authorization。

Learning outcomes

1. 完整 flow

User signs in
   ↓
Auth verifies credential
   ↓
Session / access token
   ↓
Authenticated API request
   ↓
Platform verifies token
   ↓
Database user context
   ↓
RLS policy

2. JWT 是 signed claims container

常見 JWT payload 可被 client 讀取;安全性主要依賴 signature verification 防止未授權修改,而不是內容「沒人看得到」。不要把真正 secret 塞進 client-readable claims。

3. 不信任 body.user_id

{
  "owner_id": "user-B"
}

user A 可以手動改 request body。Authorization 應使用平台驗證過的 authenticated identity,而不是 client 自稱。

4. Session lifecycle

signed outsign inactiverefresh/expiresign out

UI 與 API handling 都要接受 session 可能變化。

5. Client state 不是 server truth

Browser 顯示 current user 是 UI state;request 是否 authenticated,仍由 server/platform 驗證 token。修改 client state 不應取得更多 DB permission。

Project checkpoint:Course Workspace v3

signIn()
  ↓ session
verified user.id
  ↓ SELECT courses
RLS:
  owner_id = auth identity

Debug evidence:登入成功但 query 空

  1. session 是否存在?
  2. request 是否帶 authenticated context?
  3. RLS identity expression 是什麼?
  4. row.owner_id 是否一致?

6. getClaims / getUser / getSession:三種 evidence 不一樣

Method適合回答
getClaims()這個 access token 的 verified claims 是什麼?適合保護 page / data。
getUser()Auth server 目前的最新 user record 是什麼?需要 network call。
getSession()我現在的 raw session / access token / refresh token / expiry 是什麼?

Server-side authorization 最危險的錯誤之一,是只從 client-shared cookie/storage 讀出 session object 就直接信任裡面的 user。需要驗證 identity 時,應使用 verified claims;需要最新 Auth user record 時,再向 Auth server 取得 user。

getSession()
  ≠ fresh identity verification

getClaims()
  → verified token claims

getUser()
  → current Auth server user record

Knowledge check

  1. JWT payload 可讀是否等於可任意偽造?
  2. Authentication 與 RLS 的時間順序?
  3. 為何 body user_id 不可信?
  4. 畫 sign-in 到 RLS 的 context flow。