OAuth 2.0 學習筆記
OAuth 2.0 的四種核心角色
在了解 OAuth 2.0 的運作之前，我們需要先認識參與其中的四個關鍵角色：
- Resource Owner (資源擁有者)：通常就是指「使用者本人」。使用者擁有那些客戶端準備代為存取的受保護資源。
- Resource Server (資源伺服器)：實際裝載並保管使用者受保護資源的地方。
- Client (用戶端 / 第三方應用程式)：代替使用者去存取受保護資源的應用程式。
- Authorization Server (授權伺服器)：負責驗證使用者的身分與授權意願，並核發 Token 給第三方應用程式的伺服器。
OAuth 2.0 的基本運作流程
OAuth 的核心精神在於透過授權碼與 Token 交換權限，一個最標準的基本流程可以拆解為以下四個步驟：
- 步驟 A：使用者在 Authorization Server 進行登入，並同意授權給 Client。
- 步驟 B：Authorization Server 確認授權後，回傳一組授權碼 (Authorization Code) 給 Client。
- 步驟 C：Client 拿著這組授權碼，去向 Authorization Server 換取 Access Token (存取權杖)。
- 步驟 D：Client 拿著 Access Token，正式向 Resource Server 請求並取得受保護的資料。
四種常見的授權模式 (Authorization Grants)
根據不同的應用場景需求，OAuth 2.0 定義了四種授權模式。這些模式實際上都是基於上述的「基本流程」進行適當的微調或刪減而來：
- Authorization Code (授權碼模式)
- Implicit (隱式授權模式)
- Client Credentials (用戶端憑證模式)
- Resource Owner Password Credentials (使用者密碼模式)
1. Authorization Code (授權碼模式)
這是最常見、也是安全性最高的模式。它的流程就是完整走完上述基本流程的 A 到 D 步驟。
在這個模式中，回傳的「授權碼」本身並不能直接用來存取資源，而且它的有效期限極短。Client 必須在後端伺服器拿著這個授權碼去 Authorization Server 換取 Access Token，才能真正去存取目標資源。這樣的設計能確保 Access Token 不會在瀏覽器或前端外洩。
下面來看一個我們最常見的例子：
2. Implicit Grant (隱式授權模式)
這個模式跳過了「用授權碼換 Access Token」的步驟 (即跳過步驟 C)。
當使用者同意授權後，Authorization Server 會直接把 Access Token 放在網址中回傳。這個模式通常應用於沒有後端的 SPA (Single-Page Application) 單頁式應用程式，讓前端可以直接拿著 Access Token 去呼叫 API。
因為 Access Token 在交換過程中會直接暴露在 URL 中，這個方法非常不安全，在現代的開發中已經不被推薦使用。甚至在 OAuth 2.1 中已經被棄用。
3. Client Credentials (用戶端憑證模式)
這個模式跳過了需要使用者參與的步驟 A 與 B。
在這種情境下，Client 自己本身就是資源擁有者。Client 擁有一組自己的 Secret Key，它可以直接拿著這組 Key 去向 Authorization Server 證明自己的身分，並直接換取 Access Token。通常用於內部微服務或伺服器對伺服器 (M2M) 的 API 溝通。
4. Resource Owner Password Credentials (使用者密碼模式)
這個模式同樣跳過了步驟 A 與 B。
作法是讓使用者直接把帳號密碼交給 Client，然後讓 Client 在步驟 C 拿著使用者的帳號密碼去向 Authorization Server 取得 Access Token。
這個作法也就是把密碼完全交付給了第三方，極度不安全，所以只能用在「絕對可信任」的 Client 上，例如作業系統內建的 App 或公司自家的內部應用系統。
Summary
OAuth 2.0 是一個規範，主要用來解決如何在不給出密碼的情況下，安全地讓第三方應用程式可以存取使用者在某個服務上的資源。共有四種不同模式，其中最常被應用也是最安全的為授權碼模式。
最後補充一點，包含我自己，很多人會把 OAuth 和 SSO 搞混，以為看到授權頁面就是在做登入。這其實只對了一半：SSO 通常會搭配 OIDC (OpenID Connect) 來達到「認證 (Authentication)」及「授權 (Authorization)」，而 OAuth 這個機制本身，嚴格來說只負責處理**「授權」**的部分，像是授權第三方應用存取使用者的 FB 大頭照、信箱等等。