OAuth 2.0 開放授權框架深入解析
透過 Access Token 實現安全委派授權機制
現代應用程式頻繁需要代替使用者存取第三方資源。OAuth 2.0 提供一套標準化的委派授權框架，讓第三方應用無需觸碰使用者密碼，即可安全地取得受限資源存取權。
OAuth 2.0 是授權框架，不是身分驗證協定
這是最常被混淆的關鍵。OAuth 2.0 解決的是「授權」問題——允許應用程式以使用者名義存取資源，而非驗證使用者身分。框架定義四個核心角色：資源擁有者（使用者）、客戶端（第三方應用）、授權伺服器、資源伺服器。授權完成後，客戶端僅獲得有時效性的 Access Token，而非使用者憑證。若需身分驗證，應採用建構於 OAuth 2.0 之上的 OpenID Connect（OIDC）協定，兩者職責明確分離，切勿混用。
Authorization Code Flow：最核心的授權流程
OAuth 2.0 定義多種授權流程（Grant Type），其中 Authorization Code Flow 是最安全、最廣泛採用的模式。流程分為兩階段：首先，使用者在授權伺服器登入並同意授權，客戶端取得短效的 Authorization Code；接著，客戶端以此 Code 向授權伺服器換取 Access Token。Token 攜帶 Scope（權限範圍），確保最小權限原則——例如僅讀取 Google 日曆，而非存取整個帳號。搭配 PKCE（Proof Key for Code Exchange）可進一步防止授權碼攔截攻擊，為公開客戶端提供額外保護。
GET /authorize?
response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=https://app.example.com/callback
&scope=read:calendar
&code_challenge=BASE64URL(SHA256(code_verifier))
&code_challenge_method=S256💡 重點整理
- OAuth 2.0 ≠ 身分驗證，它只處理授權，身分驗證需搭配 OIDC。
- Access Token 有時效限制，到期後須以 Refresh Token 靜默更新。
- Scope 決定最小權限，應僅申請應用實際所需的權限範圍。
- 公開客戶端必須啟用 PKCE，防止授權碼被中間人攔截替換。
掌握 OAuth 2.0 的核心在於理解「委派授權」的本質：使用者授予有限權限，應用程式以 Token 代為行事，密碼始終不離開使用者。選對 Grant Type、嚴守 Scope 最小化，即是安全實作的基石。