Authentication 與 Authorization：你是誰，和你能做什麼

1. 兩個最常被混淆的字 0:00–0:22

作者開門見山問：authorizationi 和 authenticationi 到底是什麼、差在哪、你的應用需要哪一個。他指出這兩個概念經常被混為一談，而這支影片要說明它們如何「合作」保護 APIi——注意他從一開始就把兩者定位成互補而非二選一。

推理因為 authorization 和 authentication 在日常用語裡幾乎被當成同義詞，所以作者不先給定義，而是先把問題攤成三句：它們各是什麼、差在哪、你的應用需要哪一個。接著他補上第四句，也是真正決定整支影片走向的一句——他要講的是這兩件事「如何一起」保護 API。這句話等於先否定了第三個問題裡「二選一」的暗示：答案不是挑一個，而是兩個都要，只是各管一段。

• CAuthentication：確認你是誰；問句是「你是誰」→ 畫地圖
• CAuthorization：確認已認證的人能做什麼；問句是「你能不能」→ 畫地圖

AI 補充值得補的是這兩個字為什麼特別容易混：它們都以 auth 開頭、程式庫裡都縮寫成 auth（`authMiddleware`、`auth.js` 到底是哪一個？），而且常常被塞進同一個 middleware 一起執行。連 HTTP 協定自己都搞錯過——狀態碼 401 的正式名稱是 Unauthorized，但它真正的意思是「你還沒認證」，而「認證過了但沒權限」是 403 Forbidden。也就是說，這個混淆不只是初學者的問題，它已經固化在我們每天用的工具與規格裡，所以值得花一支影片把它分乾淨。

2. 辦公大樓比喻：進得了門 0:22–1:04

作者用一個真實場景取代定義：你到高科技公司上班，在門禁鍵盤輸入識別碼，保全系統掃你的臉。系統做兩件事——確認這個識別碼屬於某位員工，並比對臉部資料確認你就是本人。通過後發給你一張通行證，證件上編碼了你的身分資訊與你在公司裡的角色i。這整段就是真實世界的 authentication。

推理因為上一段刻意不給定義，所以作者接著用一個幾乎每個人都做過的動作來代替定義：在門禁鍵盤輸入識別碼、被掃臉、拿到通行證。他把保全系統的動作明確拆成兩步——先確認這個識別碼屬於一位在這裡工作的員工，再拿臉部掃描比對檔案，確認你就是你聲稱的那個人——然後才把名字補上：你剛剛經歷的就是真實世界的 authentication。順序是刻意的：先有體感，再有名字，這樣名字就不會退回成一個和另一個字長得很像的空殼。

• CRole：通行證上編碼的身分分類，給人看的「你是哪一類人」→ 畫地圖
• RMulti-factor authentication：識別碼＋臉部掃描，兩步缺一步就能被冒充→ 存＋回想

AI 補充作者拆出的兩步其實有各自的名字，值得分開看：輸入識別碼是 identification（你宣稱你是誰），掃臉是 verification（證明你的宣稱為真）。少了第二步，任何人知道你的識別碼就能變成你——這也是為什麼真實的門禁很少只有鍵盤。另外，這段有一句容易滑過去、但其實是整支影片最重要的伏筆：「通行證上編碼了你的資訊與你在公司裡的角色」。這代表認證的產物不只是一個「通過／不通過」的布林值，而是一張帶著資料的憑據。如果通行證上只寫「此人已認證」，那麼大樓裡每一扇門都無從判斷該不該開——後面所有的推論都建立在「這張證上寫了角色」這件事上。

術語:credentialsimulti-factor authenticationi

3. Web 版的認證：換成 token 1:04–1:40

作者把比喻一比一搬到 web 應用：使用者交出帳號密碼這組 credentials，系統確認這個使用者存在、密碼與資料庫相符，然後發出一個 tokeni。token 上編碼了使用者是誰、以及他在應用裡的角色——正好對應通行證上的資訊。關鍵在頻率：這通常一個 sessioni 只發生一次，access tokeni 有到期時間，使用者也許一天只認證一次。

推理因為上一段把認證的產物定調為「一張帶資料的憑據」，所以作者接著要證明這個結構在真實系統裡確實成立：使用者交出 credentials → 系統確認這個使用者存在、再確認密碼與資料庫相符 → 發出一個 token，token 上編碼了他是誰以及他在應用裡的角色。翻譯完成之後，他多說了一件故事裡沒有的事——頻率：這通常一個 session 只發生一次，access token 有到期時間，使用者也許一天只需要認證一次。這句聽起來像順帶補充，其實是他等一下要拿來對比的那把尺。

• CAccess token：短期通行證，編碼了身分與角色，取代每次重送密碼→ 畫地圖
• CClaim：token 裡編碼的一項宣稱，例如 sub 是誰、exp 何時過期、roles 是角色→ 畫地圖
• Aaccess token 是短期可撤銷的替身，密碼是外洩就永久失守的長期機密→ 批判類比
• RSession 與 access token 的頻率關係→ 存＋回想

AI 補充有兩件作者跳過的事值得補。第一，token 上「編碼的那些資訊」在規格裡有名字，叫 claims（宣稱i），例如 sub 是使用者是誰、exp 是到期時間、roles 是角色；後面所有的權限判斷讀的就是這些欄位。第二，為什麼要發 token，而不是每次請求都重送一次帳號密碼？因為密碼是長期祕密，一旦在某次請求中外洩，攻擊者拿到的是永久通行權；token 則是短期、可設定到期、可以撤銷、還能限定用途的替代品。換句話說，發 token 這一步的重點不只是方便，而是把「長期祕密」換成「短期憑據」，讓外洩的損害有時間上限。另外，作者一句帶過的「比對密碼」在實務上並不是字面上那樣做——見本段勘誤。

4. 認證擋不住的那件事 1:40–2:01

作者指出 authentication 的能力邊界：它擋掉匿名使用者，讓你知道是誰在存取系統，某種程度上也能依「使用者是誰」控制他看到什麼。但它擋不住一個已經通過認證的人去碰你不想給他的資源i。這個缺口就是 authorization 存在的理由。

推理因為上一段的 token 讓系統知道了「你是誰」，所以作者接著做一件推理上必要的事：把「知道你是誰」能換來的保護先列出來——擋掉匿名使用者，所以你知道是誰在存取系統；某種程度上也能依據使用者是誰來控制他看到哪些資源——然後在同一句話裡踩煞車。他的轉折句下得很準：你真正還需要的，是一個辦法阻止「已經通過認證的」使用者去存取你不希望他碰的資源。威脅的身分在這一句裡從外人變成了內部人，門檻也就從「你是誰」變成「你能做什麼」。authorization 是被這個缺口逼出來的，不是作者硬塞進來的。

• CIDOR：改網址上的 id 就看到別人的資源，認證通過但授權缺失的典型漏洞→ 畫地圖
• A把權限寫死成 if user.id === 42，就像程式裡到處散落的硬編碼特例→ 批判類比
• E把網址 /invoices/1001 改成 /invoices/1002，直接看到別人的帳單→ 存＋演練
• P手動測一次自己的 API 有沒有 IDOR 漏洞→ 練習
• RAnonymous access：認證擋下的是匿名使用者→ 存＋回想

AI 補充作者說「某種程度上你可以根據使用者是誰控制他看到什麼」，這一步其實已經在做授權了，只是把授權規則直接寫死在身分上（`if user.id == 42`）。這種寫法在使用者只有幾個時能動，人一多就會散落在程式各處、無人敢改——這正是「把身分」和「能做什麼」拆開的動機。另外值得補一個具體的失敗樣貌：只有認證沒有授權的系統，最典型的漏洞是 IDORi——網址是 `/invoices/1001`，你把它改成 `/invoices/1002` 就看到別人的帳單。攻擊者完全合法地登入、token 完全有效、每一次請求都通過認證，但他拿到了不屬於他的東西。這就是作者說的「認證擋不住的那件事」的實際長相。

術語:anonymous accessi

5. 拿著通行證仍被擋在門外 2:01–2:49

作者把同一個大樓故事往前推：你想上頂樓看研發實驗室，刷卡卻亮紅燈。你明明有通行證、明明已經在大樓裡——保全系統做的是讀取通行證上編碼的角色，判定你沒有被授權進入那個區域。回到自己的辦公室刷卡就亮綠燈。同一張通行證、不同的門，結果不同，差別只在權限i。

推理因為上一段把 authorization 定義成「擋住已經通過認證的人」，所以作者需要一個畫面能同時滿足兩個條件：這個人確實已通過認證，而且確實被擋下來。頂樓的研發實驗室正好——他刻意連問三句「你明明有通行證、你已經通過認證、你人就在大樓裡」，把認證這個變數釘死，讓紅燈的原因只剩下一個：保全系統讀了通行證上編碼的角色，判定你沒有被授權進入那個區域。接著他讓你搭電梯下樓，刷自己辦公室的門，亮綠燈。同一個人、同一張通行證、不同的門，結果相反——差別就只可能出在那扇門要求什麼。

• CDeny by default：讀卡機沒看到允許依據就拒絕，漏寫規則的後果是打不開門→ 畫地圖
• E同一人同一張通行證：刷實驗室門紅燈，刷自己辦公室門綠燈→ 存＋演練

AI 補充這個紅燈綠燈的對照真正的價值，是它把授權判斷的兩個輸入分開了：一邊是主體帶來的（你的角色，寫在證上），一邊是客體要求的（這個區域需要什麼角色才能進）。判斷發生在兩者相遇的那一刻，所以它必然是逐扇門各判各的——這對應到系統設計上一句很重要的話：授權是每個資源自己的事，不能只在入口做一次。還有一個細節值得指出來：讀卡機是因為「沒看到允許的依據」而亮紅燈，不是因為「看到了禁止的規則」。這叫預設拒絕i，也是所有存取控制i系統應有的預設值——漏寫一條規則的後果應該是打不開門，而不是門大開。作者沒說破這件事，但他描述的行為完全符合。

6. 每次存取都要再檢查一次 2:49–3:14

作者從故事抽出通則：能進大樓不代表能去任何地方。搬到 web 應用，每一次使用者要存取一個資源，應用程式都應該檢查他是否被授權，做法就是檢查編碼在 access token 上的 roles。這裡出現和第 3 段的頻率對照——認證一次，授權每次。

推理因為上一段已經用紅燈綠燈把畫面演完了，所以作者接著只需要把它換成一句可執行的規則：被允許進入大樓不代表被授權去任何地方；相對應地，每一次使用者要存取一個資源，應用程式都應該檢查他是否被授權，通常的做法就是檢查編碼在 access token 上的 roles。這一句同時把前面幾段的零件全部接上——第 3 段發出的 token、第 2 段寫在通行證上的角色、第 5 段那台逐扇門各判各的讀卡機。第 3 段量出的那把尺也在這裡完成對照：認證一個 session 一次，授權每一次存取都做。

• CRBAC：以 role 為單位做授權判斷，檢查 access token 上的 roles→ 畫地圖
• E只在前端隱藏按鈕、或只在 gateway 檢查一次，都不是真正的授權檢查點→ 存＋演練
• P檢查自己 API 是不是把授權判斷放在最接近資料的那一層→ 練習
• RToken revocation：只檢查 token 裡的 roles 有個代價→ 存＋回想

AI 補充「每次都檢查」聽起來理所當然，但它是實務上最常漏掉的一步，而且失敗的方式很固定。最常見的是把授權寫在前端——沒有權限就不顯示那顆按鈕；畫面看起來對了，但 API 仍然照收請求，任何人用 curl 就繞過去了。第二種是只在 API gateway 或登入時檢查一次，之後內部服務彼此信任，於是一個入口被繞過就全面失守。真正的檢查點必須落在資源被讀寫的那一層，也就是最接近資料的地方。另外，作者說的「檢查 token 上的 roles」是最簡單也最快的做法，但它有一個內建的代價——見本段勘誤。

術語:RBACitoken revocationi

7. 會計軟體：role 包住 permission 3:14–4:15

作者用會計軟體把 role 拆得更細：公司負責人、付款管理員（可執行付款、看銀行帳戶）、文書人員（只能基本資料輸入）。每個 role 包住一組更細的 permission，例如付款管理員含有 create payments 與 read payments。使用者要「建立付款」時，應用程式檢查他有沒有那個 role 或那個 permission，沒有就拒絕——即使他已經通過認證。最後點明頻率差異：授權每次都做，認證一個 session 一次。

推理因為上一段的規則停在「檢查 roles」，所以作者接著必須說明 role 內部的結構，否則這條規則無法落地成程式。他先列三個角色：公司負責人、付款管理員（可執行付款、看銀行帳戶）、文書人員（只能做基本資料輸入、只看得到有限的資料）；再說每一個角色都包住一組更細的 permission，並舉例付款管理員這個 role 含有 create payments 與 read payments。兩層於是分開了：role 是給人看的（你是哪一類人），permission 是給資源看的（可以做哪一件事）。接著他完整跑一次判斷：使用者要建立付款 → 檢查他有沒有 payment administrator 這個 role、或有沒有 create payments 這個 permission → 有就放行，沒有就拒絕，即使他已經通過認證。最後他把兩者的頻率並排說出來——授權每次都做，認證一個 session 一次——親手驗收了第 3 段量下的那把尺。

• CPermission：給資源看的「可以做哪一件事」，比 role 更細一層→ 畫地圖
• CPrinciple of least privilege：新角色從零權限開始逐項加，不是從管理員複製再刪→ 畫地圖
• E付款管理員 role 包含 create payments 與 read payments 兩個 permission→ 存＋演練
• R角色數量失控時該換的模型→ 存＋回想

AI 補充為什麼要多一層，而不是把權限直接掛在人身上？因為這兩件事的變動速度不一樣：permission 隨功能長（每加一個功能就多幾個），role 隨組織長（每來一個員工就要指派）。中間隔一層 role，「新增一個功能」和「新來一個同事」就不會互相干擾——新功能只需要決定掛進哪些角色，新同事只需要指派角色。另外要補作者沒說的兩個實務問題。第一是角色設計的預設值：新角色該從零權限開始逐項加，而不是從管理員複製再刪——後者幾乎必然留下多餘的權限。第二是角色爆炸：當規則開始出現「只能看自己部門的付款」這種條件時，用角色表達就得切出「北區付款管理員」「南區付款管理員」……角色數量開始失控，這時該換的是模型而不是再多切幾個角色。

術語:principle of least privilegeiABACi

8. 並排總結：一次 vs 每次 4:15–4:51

作者把兩個概念並排收尾：authentication 是使用者提出憑證（帳密、或臉部掃描這類生物特徵i）換取進入系統，通常一個 session 一次；authorization 在每次存取資源時發生，判斷這個已認證的使用者有沒有權限碰這個資源，沒有就拒絕。兩者不是二選一，是一起保護 API。

推理因為上一段已經把 role 與 permission 拆到底，所以作者不再引入任何新東西，改做對齊：authentication 是使用者提出一組憑證（帳號密碼，或甚至臉部掃描這種生物特徵資料）換取進入系統，通常一個 session 一次；authorization 則在每一次使用者存取資源時發生，判斷一個已通過認證的使用者對某個特定資源有沒有權限，沒有就拒絕。兩句話的差異被壓成三個維度——輸入是什麼（憑證，或已確定的身分加上資源）、問什麼（你是誰，或你能不能）、多久做一次（一次，或每次）。最後一句話回到第 1 段的開場：這兩個概念是一起工作來保護 API 的，不是二選一。整支影片在這裡閉合。

• A臉、指紋外洩換不了，密碼外洩可以直接重設→ 批判類比
• E401 正式名稱是 Unauthorized，但意思其實是「還沒認證」不是「沒權限」→ 存＋演練

AI 補充補一個可以立刻用上的記法：HTTP 的 401 對應認證失敗，403 對應授權失敗。也就是說 401 的意思是「我不知道你是誰，請先證明」，403 的意思是「我知道你是誰，但你不能碰這個」。401 的正式名稱 Unauthorized 是規格上的歷史誤稱，它其實講的是 authentication——知道這一點，看別人的 API 就不會被名稱誤導。另外要補一件作者輕輕帶過的事：他把生物特徵和帳號密碼並列成憑證，但兩者性質差很多——密碼外洩可以更換，臉和指紋不能。所以生物特徵在設計上通常只當多因素中的一個因素（見第 2 段），並且比對應該發生在使用者的裝置裡（裝置驗證通過後才代為簽章），而不是把臉的資料上傳到伺服器比對。

術語:401 Unauthorizedi403 Forbiddeni

9. 難的是實作，下一步是 Auth0 4:51–5:40

作者提醒：這兩者是安全 web app 設計的重要部分，但不容易做對、做好。他預告後續會介紹 Auth0i 這個服務代勞認證的粗活，並示範在 .NET Core 與 NestJS 裡實作 authorization 與 authentication。這替觀眾指出從概念到實作的下一段路。

推理因為上一段把兩個概念壓縮成兩句可以背的話，所以作者必須馬上補上一句相反方向的提醒：這兩件事是安全 web app 設計的重要部分，但不容易做對、做好。順著這句，他給出兩條具體的下一步——介紹 Auth0 這個服務，把認證的粗活交出去；以及在 .NET Core 與 NestJS 裡實際實作一次 authorization 與 authentication。整支影片於是從「分辨兩個字」，收在「接下來去哪裡」。

• RIdentity Provider／Auth0：可以外包的是認證的粗活→ 存＋回想

AI 補充作者說 Auth0 代勞的是「認證」的粗活，這個用字其實透露了一個重要的分野，值得補完：認證的難處在於一大堆跟你的業務完全無關、卻極容易做錯的細節——密碼儲存與雜湊、暴力破解與速率限制、多因素、社交登入、帳號復原、session 與 token 生命週期。這些每個產品的需求幾乎一樣，所以外包給專門的服務是合理的。授權剛好相反：規則來自你的業務本身（誰可以建立付款、誰能看哪個部門的資料），沒有人比你更清楚，也沒有服務能替你決定。外部服務能提供的是承載與執行規則的機制，規則本身仍得你自己設計。這解釋了為什麼作者說 Auth0 做的是認證的重活，而不是把兩件事一起交出去。另外補一個時間背景：Auth0 在這支影片上傳前一個月（2021 年 5 月）剛被 Okta 併購，現在通常被歸在 Okta 的產品線下，同類型的選擇還有 Keycloak（開源、可自架）、AWS Cognito、Firebase Authentication 等。

術語:Identity ProvideriOpenID Connecti