Authorization 權限控管

決定已登入使用者能做什麼。

先用一句話理解

決定已登入使用者能做什麼。

打個比方

像員工證能進公司，但不同門禁能開的門不一樣。

什麼時候會遇到

有管理員、普通會員、團隊、客戶資料隔離時。

再往深一點看

Authorization（權限控管）在 Authentication（身份驗證）之後才發生——系統先知道你是誰，再決定你能做什麼。最常見的做法是角色（Role）：admin 能刪除所有資料，editor 只能改自己的文章，viewer 只能讀取。更細緻的設計叫做 Row-Level Security（RLS），例如 Supabase 支援直接在資料庫層設定「這筆資料只有擁有者能讀」，讓即使 API 寫法有漏洞，資料庫也不會把不該給的資料吐出來。權限控管必須在後端或資料庫層執行，前端的顯示隱藏只是 UI，不是安全防線。

舉個例子

你做一個多租戶 SaaS：用 Clerk 的 Organization 功能給每個客戶公司建一個組織，admin role 可以邀請成員和刪除資料，member role 只能看自己的紀錄。後端每支 API 都先檢查呼叫者的 role，資料庫再用 RLS 確保跨租戶的資料完全隔離。

常見誤解

- 只在前端隱藏按鈕或頁面，後端沒有對每個 API 做 role 檢查，懂技術的使用者直接呼叫 API 就能繞過所有限制。
- 把所有資料都放同一張表卻沒加 RLS 或 user_id 過濾，API 邏輯一旦有個疏漏，A 使用者就能讀到 B 使用者的資料。
- 把 Authorization 和 Authentication 的錯誤回應搞混——身份驗證失敗要回 401，權限不足要回 403，前端才能正確判斷要跳登入頁還是顯示「無權限」訊息。