想像一下，你做了一個線上課程網站。有人買了課程，他當然要能看；沒買的人，就不能看。這時候問題來了——你怎麼知道誰是誰？誰買了什麼？
這就是「權限驗證」要解決的事。
不管你是做：
- 會員網站（誰能登入？）
- 網頁遊戲（這個玩家有什麼裝備？）
- 後台系統（誰是管理員？）
都躲不掉這個問題。
在開始之前，先記住一個大原則：
跟人打交道 = 麻煩事很多
跟機器打交道 = 相對單純
這也是為什麼權限驗證會分成兩種：Client to Server（跟人）和 Server to Server（跟機器）。
Client to Server（使用者 → 伺服器）
什麼是 Client to Server？
Client 就是「使用者端」，可以是：
- 網頁瀏覽器（Chrome、Safari）
- 手機 App
簡單說，就是一般人在用的東西。
Client to Server 講的就是：使用者從瀏覽器或 App 登入，然後連到你的伺服器。
為什麼 Client 端驗證比較複雜？
因為「人」很難控制。使用者可能是正常用戶，也可能是想搞破壞的駭客。你沒辦法知道螢幕另一端是誰，所以防護要做很多層。
一句話：只要碰到「人」的地方，就要特別小心！
例子一：帳號密碼登入
這個大家都懂，流程很單純：
- 你輸入帳號、密碼
- 網站把這些資料送到伺服器
- 伺服器去資料庫查：「有沒有這個人？密碼對不對？」
- 對了就讓你進去，錯了就踢你出來
sequenceDiagram
participant C as 👤 Client<br/>(瀏覽器/App)
participant S as 🖥️ Server<br/>(伺服器)
participant D as 🗄️ Database<br/>(資料庫)
C->>S: 1. 送出帳號、密碼
S->>D: 2. 查詢：這組帳密對不對？
D-->>S: 3. 回傳結果（對 / 錯）
S-->>C: 4. 登入成功 ✅ 或 登入失敗 ❌簡單粗暴，但很有效。
例子二：用 Facebook / Google 登入
現在很多網站都有「使用 Google 登入」「使用 FB 登入」的按鈕，這種叫做第三方登入。
為什麼要用這個？
- 使用者懶得再記一組帳密
- 網站不用自己處理密碼（密碼外洩很可怕）
- 可以直接拿到使用者的名字、Email
流程是這樣的（三步驟）
第一步：瀏覽器跟 Google 說「我想要什麼資料」
使用者在你的網站點擊「使用 Google 登入」後，瀏覽器會發送請求到 Google，告訴 Google：「我想要取得這個使用者的姓名和 Email。」
這個「想要拿的資料範圍」就叫做 Scope。
第二步：使用者在 Google 登入並同意授權
Google 會跳出一個登入畫面，使用者輸入 Google 的帳號密碼。登入成功後，Google 會再問：「某某網站想要你的姓名和 Email，你同意嗎？」
使用者按下同意後，Google 會把「通行證」（Token）回傳給瀏覽器。
第三步：你的伺服器拿通行證去換資料
瀏覽器收到 Token 後，會把它交給你的伺服器。
接著，你的伺服器拿著這個 Token 去跟 Google 說：「這是剛才那個使用者給我的通行證，現在可以給我他的資料了吧？」
Google 確認沒問題後，就把姓名、Email 回傳給你的伺服器。
sequenceDiagram
participant C as 👤 Client<br/>(瀏覽器)
participant S as 🖥️ Server<br/>(你的伺服器)
participant G as 🌐 Google/FB<br/>(第三方)
C->>G: 1. 點擊「使用 Google 登入」
Note over C,G: 告知想要的資料（Scope）：姓名、Email
G->>C: 2. 跳出登入畫面
C->>G: 3. 輸入帳密 + 同意授權
G-->>C: 4. 回傳 Token（通行證）
C->>S: 5. 把 Token 交給你的伺服器
S->>G: 6. 拿 Token 去換資料
G-->>S: 7. 回傳使用者的姓名、Email
S-->>C: 8. 登入成功 ✅搞定！
Server to Server（伺服器 → 伺服器）
什麼是 Server to Server？
這是你的伺服器去串接「別人的伺服器」。
舉個例子，你做了一個電商網站，可能需要：
- 串金流（綠界、藍新）→ 讓客人可以付款
- 串物流（黑貓、7-11）→ 讓商品可以寄出去
- 串簡訊服務（Twilio）→ 發驗證碼給客人
這些都是你的伺服器去跟別人的伺服器「對話」。
為什麼伺服器之間的驗證比較簡單？
因為雙方都是「機器」，而且：
- 有防火牆保護：伺服器不會直接暴露在網路上
- 可以設白名單：只讓特定的 IP 連進來，其他一律擋掉
- 環境可控：不用擔心有人亂搞
所以驗證方式就不用像 Client to Server 那樣搞一大堆。
例子一：API Key（固定金鑰）
這是最常見的方式。
當你去申請串接金流或簡訊服務時，對方會給你一組「金鑰」，長得像這樣：
API_KEY=a1b2c3d4e5f6g7h8i9j0之後你的伺服器每次發請求，都要帶上這組金鑰。對方收到後會檢查：「這把鑰匙是不是我發出去的？」對了就讓你用，錯了就擋掉。
就像你拿鑰匙開門一樣，認鑰匙不認人。
例子二：SSL 憑證（公鑰 / 私鑰）
這個稍微進階一點，用的是「非對稱加密」。
簡單說就是：
- 你手上有一把「私鑰」（只有你知道）
- 對方手上有一把「公鑰」（你給他的）
當你發請求時，用私鑰「簽名」。對方收到後，用公鑰去驗證：「這個簽名是不是你簽的？」
這種方式比 API Key 更安全，因為就算有人攔截到你的請求，沒有私鑰也沒辦法偽造。
銀行、政府機關的系統串接通常會用這種方式。
重點整理
Client to Server（使用者 → 伺服器）
- 面對的是「人」，所以很複雜
- 常見方式：帳號密碼登入、第三方登入（FB / Google）
Server to Server（伺服器 → 伺服器）
- 面對的是「機器」，有防火牆和白名單保護，相對單純
- 常見方式：API Key（固定金鑰）、SSL 憑證（公鑰私鑰）
結語
記住那句話：只要接觸到「人」的地方，都要特別小心處理。
這就是為什麼 Client to Server 的驗證方式那麼多、那麼複雜，而 Server to Server 可以相對簡單的原因。
希望這篇有幫到你！