前言

上一篇的最後提到 OAuth 2.0 其實是一個「授權框架」，而不是「驗證方法」。這句話聽起來像文字遊戲，但搞懂它，才能理解接下來要拆解的各種 Grant Type，到底在解決什麼問題。這篇先把 OAuth 2.0 最基礎的角色、流程與權限範圍講清楚，作為後續 Grant Type 的共同基礎。

實務上你也會看到很多文章把 Grant Type 稱為 OAuth Flow，例如 Authorization Code Flow、Implicit Flow、Device Flow。嚴格說起來，Grant Type 指的是 Client 取得 Access Token 的授權方式；Flow 則比較像是這個授權方式實際跑起來的流程。多數文章會混用這兩個詞，這篇後面也會視語境交替使用。

今天內容涵蓋:

1. OAuth 2.0 的四個核心角色
2. Client 的兩種類型:Public 與 Confidential
3. 抽象協定流程(Abstract Protocol Flow)
4. Scope:Client 到底要什麼權限
5. OAuth 2.0 是「授權框架」，不是「驗證方法」
6. 從 RFC 6749 的 4 種 Grant Type，到 2026 年的實務分類

一、OAuth 2.0 的四個核心角色

RFC 6749 在 1.1 節開頭就定義了 OAuth 2.0 的四個角色，少了任何一個，整個授權流程都無法成立:

💡Authorization Server 跟 Resource Server 可以是同一台伺服器，也可以是分開的兩個系統；一個 Authorization Server 簽發的 Access Token，也可以被多個 Resource Server 接受。

二、Client 的兩種類型:Public 與 Confidential

RFC 6749 對 Client 還有一層更細的分類，這層分類會直接決定 Client 能用哪種 Grant Type:

這個分類直接影響安全性設計:

• Public Client 不該使用需要出示 client_secret 的 Grant Type，因為它沒有真正「保密」的能力，只能靠其他機制來彌補沒有 client_secret 的缺口(後面各篇會分別展開)。
• Confidential Client 才適合用需要出示 client_secret 的 Grant Type，因為 client_secret 能被安全存放在伺服器端，不會暴露給使用者。

⚠️Mobile App、桌面應用程式雖然理論上有系統層級的安全儲存機制(例如 Keychain)，但大多數框架仍把它們歸類為 Public Client——因為它們會被發佈、安裝到使用者的裝置上，預設「使用者端拿得到裡面的東西」是比較安全的假設。

三、抽象協定流程(Abstract Protocol Flow)

RFC 6749 可以用一張圖把四個角色的互動關係畫出來:

六個步驟拆開來看:

1. Client 發起 Authorization Request，通常是把 Resource Owner 導向 Authorization Server，請求使用者同意授權。這個請求裡會帶上 Client 想要的權限範圍(scope)、授權完成後要導回哪裡(redirect_uri)等資訊。
2. Resource Owner 同意後，Client 拿到一張「Authorization Grant」——代表取得授權的依據，實際型態依 Grant Type 而不同(可能是一段授權碼，也可能是使用者的帳密；但要注意，直接拿帳密當 Grant 的做法，正是後面會提到、現在已被 RFC 9700 建議禁用的 Resource Owner Password Credentials Grant)。
3. Client 拿著 Authorization Grant，去跟 Authorization Server 換 Access Token。
4. Authorization Server 驗證 Client 身分跟 Authorization Grant 是否有效，通過就發出 Access Token。
5. Client 帶著 Access Token 去跟 Resource Server 要資源。
6. Resource Server 驗證 Access Token 有效，就回傳受保護的資源。

💡技術上，Resource Owner 可以只同意部分權限、也能隨時撤回；法規上，GDPR(歐盟資料保護法規)等資料隱私法規也要求必須取得明確同意。這就是為什麼 Authorization Server 一定要有清楚的同意畫面——而同意的具體內容，就是後面第四節會談到的 Scope。

這裡要先建立一個概念：「Authorization Grant」跟「Access Token」不是同一個東西。Authorization Grant 是 Client 用來向 Authorization Server 證明「我已經取得授權，可以來換 Access Token」的憑證或依據；Access Token 才是實際拿去呼叫 Resource Server 的憑證。

後面要介紹的 Authorization Code、Implicit、Resource Owner Password Credentials、Client Credentials，都是 RFC 6749 定義的不同 Grant Type，差別主要在於 Client 如何取得授權、Access Token 如何被核發。實際流程不一定會完整照著這張抽象圖的六個步驟逐一發生，但這個架構概念本身沒有變。

⚠️RFC 6749 雖然列出 Implicit 跟 Resource Owner Password Credentials 這兩種 Grant Type，但在後來的 RFC 9700(OAuth 2.0 Security Best Current Practice)中都已不被建議使用，具體原因與取代方案會在 之後分別展開。

四、Scope — Client 到底要什麼權限

OAuth 2.0 沒有規定 Resource Server 要長什麼樣子，也沒有規定資源要怎麼切分。這件事通常靠 Scope 參數來表達：Client 在請求裡帶上 Scope，說明「我想要哪些權限」，Authorization Server 跟 Resource Server 再依照共同約定好的值決定是否放行。

OAuth 2.0 沒有規定 Scope 字串要怎麼寫，不同 Authorization Server 會有自己的寫法(也就是命名慣例)，常見的有:

以上面 [動作]:[資源] 的 read:orders 為例，下圖實際畫出 User、Client、Authorization Server、Resource Server 四方如何靠 Scope 來協調權限：

💡Scope 的實際命名跟意義，OAuth 2.0 本身不規定，需要 Client、Authorization Server、Resource Server 三方自己約定好。到了 OIDC，才有 openid、profile、email 這種標準化的 Scope，這部分會在後面 OIDC 的章節提到。

五、OAuth 2.0 是「授權框架」，不是「驗證方法」

這一節要說明的核心概念是：OAuth 2.0 要回答的是「這個 App 可以存取什麼？」（Authorization，授權），而不是「這個使用者是誰？」（Authentication，驗證）。

實務上容易搞混，是因為 Authorization Server 在發 Access Token 之前，通常會先驗證 Resource Owner 的身分。這個前置動作讓很多人誤以為拿到 Access Token 就等於「使用者已經登入驗證成功」；但 Access Token 本質上是「這個 App 有沒有權限」的證明，不是用來代表使用者身分的憑證。

也就是說，OAuth 2.0 流程中確實常常會出現登入畫面，但登入只是 Authorization Server 確認 Resource Owner 身分、取得授權同意的前置步驟；整個 OAuth 2.0 流程真正產出的核心結果，仍然是 Access Token，而不是用來代表登入身份的 ID Token。

真正要解決「這個使用者是誰」的問題，靠的是建立在 OAuth 2.0 之上的 OpenID Connect(OIDC)。OIDC 會額外多發一個 ID Token，裡面才有使用者身分的宣告；這部分會在之後深入拆解。

💡這個混淆不是巧合，因為機制上兩者本來就是共用的：OIDC 的 Authentication Request，其實就是在 Authorization Request 的基礎上，多要求「順便驗證使用者身分」而已，具體怎麼做會在後面 OIDC 的章節詳細說明。也因為兩者共用同一套請求機制，Authorization 跟 Authentication 這兩個詞，實務上才會常常被搞混。

六、從 RFC 6749 的 4 種 Grant Type，到 2026 年的實務分類

RFC 6749 原始只定義了 4 種 Grant Type:

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

但十幾年下來，隨著裝置型態變多、安全事件累積，社群也依據 RFC 6749 8.3 節預留的擴充機制，陸續推出新的 Extension Grant，例如 Device Authorization Grant、JWT Bearer Grant、SAML 2.0 Bearer、Token Exchange；同時，幾種舊流程也被正式列為不建議使用。

如果只看新系統的常見選擇，可以先抓住兩個大方向：有使用者參與時，優先使用 Authorization Code + PKCE；沒有使用者參與、純服務對服務時，使用 Client Credentials。其他 Grant Type 大多是為了特殊裝置、企業整合或歷史相容性而存在。

到了 2026 年，實務上大致可以整理成:

💡這張表不是單一官方文件的排行榜，而是綜合 RFC 9700(OAuth 2.0 Security Best Current Practice)明確禁用 Resource Owner Password Credentials、不建議 Implicit 的立場，加上 OAuth 2.1 草案將 Authorization Code + PKCE 訂為預設流程的走向，以及目前業界對其他 Grant Type 的普遍用法整理而成，並非某個官方年度評級。

小結

這篇先把 OAuth 2.0 的基礎架構整理起來。要看懂後面的各種 Grant Type，最重要的是先抓住幾個概念：

1. OAuth 2.0 有四個核心角色：Resource Owner 擁有資源，Client 想存取資源，Authorization Server 負責核發 Access Token，Resource Server 則負責保護實際資源。
2. Authorization Grant 和 Access Token 不是同一個東西：Authorization Grant 是 Client 用來證明「我已取得授權」的依據；Access Token 才是實際拿去呼叫 API 的憑證。
3. Client 類型會影響安全設計：Confidential Client 可以安全保存 client_secret；Public Client 無法安全保存密鑰，因此後面會需要 PKCE 等額外保護。
4. Scope 用來描述權限範圍：Client 透過 Scope 告訴 Authorization Server 自己想要哪些權限，Resource Server 再依照 Token 中的權限決定是否放行。
5. OAuth 2.0 不是身份驗證協定：它主要回答「這個 Client 能不能存取資源」，不是「目前登入的使用者是誰」。真正要標準化身份驗證，後面會交給 OIDC 補上。

下一篇會從最常見的 Authorization Code Grant 開始，實際看使用者授權第三方 App 時，OAuth 2.0 如何透過「先拿 Code、再換 Token」的方式降低 Access Token 直接暴露的風險。

參考資源

• 什麼是 OAuth 2.0 - Apifox
• OAuth - Wikipedia
• OAuth 介紹 - Google Cloud Apigee
• 常見的 OAuth 2.0 Grant Types - Authgear
• OAuth2 & OIDC: All Of The Specs (2026 Edition) - Medium
• What is OAuth 2.0 and How It Works - Authgear
• 身份驗證解決方案指南 - Authgear
• OAuth 2.0 筆記 - HackMD
• Sa-Token OAuth2 文件
• What is Client? - Auth Wiki
• What is Authentication request? - Auth Wiki
• What is Resource owner? - Auth Wiki
• What is Resource server? - Auth Wiki
• RFC 6749: The OAuth 2.0 Authorization Framework - IETF
• OAuth 2.0 授權 (Grant) 是什麼？ - Auth Wiki by Logto