認證三兄弟：API Key / OAuth / JWT

情境：三種「你是誰」的驗證方式

你的電商平台要跟三個外部服務整合：

1. 一個商品庫存查詢 API
2. 用 Google 登入的購物功能
3. 一個自動通知客服的系統

這三個情境，用的是三種完全不同的認證方式。搞不清楚差別，你可能選了最麻煩的方式，或是用了不夠安全的方式。

---

API Key：家門鑰匙

什麼是 API Key？

API Key 就像一把家門鑰匙：拿到了就能開門，不需要問「你是誰」。

優點與缺點

優點	缺點
簡單，一串字串就搞定	沒有細粒度的權限控制
容易整合	Key 一旦洩漏，什麼都能做
適合伺服器對伺服器呼叫	不適合代表特定「用戶」

適合用在哪？

• 你的後端呼叫第三方服務（天氣 API、地圖 API、簡訊 API）
• 伺服器對伺服器，沒有「最終用戶」的概念
• 範例：Google Maps Static API、Twilio SMS、各種 SaaS API

---

OAuth：飯店房卡

什麼是 OAuth？

OAuth 就像飯店的電子房卡：你告訴飯店「我要借張卡給我的訪客」，飯店給一張只能開特定門的卡，而且卡可以隨時停用。

你不需要把主鑰匙（帳號密碼）給訪客。

OAuth 的流程（用 Google 登入為例）

1. 使用者點「用 Google 登入」
2. 瀏覽器跳轉到 Google 登入頁面
3. 使用者在 Google 輸入帳密（你的網站看不到這組帳密！）
4. Google 問使用者：「這個網站要讀取你的姓名和 Email，同意嗎？」
5. 使用者同意
6. Google 給你的網站一個「Access Token」
7. 你的網站用這個 Token 向 Google 取得用戶資料

關鍵概念

概念	說明	飯店房卡比喻
授權（Authorization）	用戶同意你存取他的資料	房客同意借卡給訪客
範圍（Scope）	你只能存取被授權的資料	卡只能開特定的門
Token 撤銷	用戶可以隨時取消授權	可以隨時停用那張卡
Refresh Token	Token 到期後可以換新的	短期有效，快到期換新卡

適合用在哪？

• 代表某個用戶存取他的資料（用 Google / Facebook / Line 登入）
• 需要精細的權限控制（唯讀 vs 讀寫）
• 範例：Google OAuth、Facebook Login、Line Login

---

JWT：護照

什麼是 JWT？

JWT（JSON Web Token）就像護照：護照裡寫了你的身份資料，而且有簽章（只有政府能發，但任何人都能驗）。你不需要每次都回政府確認你是誰，護照本身就是證明。

JWT 的結構

JWT 是一個字串，用「.」分成三段：

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIxMjM0IiwicmVsZSI6ImFkbWluIn0.signature
[Header：加密演算法]   [Payload：資料內容]                              [簽章]

Payload 解碼後長這樣（任何人都能讀，但不能偽造）：

JWT 的特性

特性	說明
自包含（Self-contained）	Token 本身攜帶身份資訊，不需要查資料庫
有簽章	內容被竄改就驗證失敗
有到期時間	Token 會過期，降低洩漏風險
無狀態	伺服器不需要儲存 Session

適合用在哪？

• 用戶登入後的身份驗證（前後端分離的架構）
• 微服務之間傳遞身份
• 範例：各家 SaaS 的 Bearer Token、Slack Bot Token 的設計概念

---

三者比較與選擇指南

情境	推薦方式	理由
後端呼叫第三方服務（庫存 API）	API Key	簡單、伺服器對伺服器
讓用戶用 Google 帳號登入	OAuth	授權流程、不拿用戶密碼
用戶登入後的 API 呼叫	JWT	無狀態、自包含身份
給合作夥伴的系統整合	API Key 或 OAuth	視是否需要精細授權而定

---

練習題

---

AI 協作：學了這個，跟 AI 怎麼配合？

了解三種認證機制，能讓你在請 AI 協助整合 API 時，給出正確的技術脈絡，避免做出不安全的設計。

你的人類優勢：

• 你知道這個 API 整合的業務情境（是用戶行為還是系統對系統）
• 你能判斷「這個整合需不需要代表特定用戶」

可以這樣跟 AI 說：

我的電商平台要讓用戶用 Google 帳號登入。我的後端是 Python Flask，前端是 React。幫我說明 OAuth 2.0 的整合流程，並給我後端的範例程式碼。注意：Google 的 Client Secret 只能在後端使用，不能出現在前端。