上一篇的 OIDC 幫 OAuth 2.0 補上了「身份驗證」，但那整個故事的前提，都是背後有一個真人使用者在瀏覽器上輸入帳密、按下同意。這篇要回到「授權（Authorization）」這一側，但換一個完全不同的場景：如果兩端都是伺服器，根本沒有使用者參與，OAuth 2.0 要怎麼處理？這就是 Client Credentials Grant要解決的問題。
這個流程在企業系統裡特別常見，例如後端服務、自動化程式或內部系統需要呼叫 API 時，通常不是代表某位使用者操作，而是由應用程式用自己的身份取得授權。本文後面也會補充 Microsoft Entra ID 的企業場景，說明它如何對應到「應用程式本身的權限」。
今天內容涵蓋:
Client Credentials Grant 是 RFC 6749 定義的四種 Grant Type 之一（§4.4）。跟前面幾篇的 Authorization Code Grant 最大的不同是：整個流程完全沒有使用者參與。Client 直接拿自己的憑證（client_id + client_secret，或憑證等其他驗證方式）當作 Authorization Grant 本身，跟 Authorization Server 換一個 Access Token。
換句話說，這個流程取得的 Access Token 代表的是 Client application 本身，而不是某位使用者。因此，Client Credentials Grant 適合用在服務與服務之間的通訊，例如批次工作、系統整合、後端服務互相呼叫，而不是用來代表使用者存取個人資料。
oauth.net 的說明很精準：這個 Grant Type 通常是「Client 用來存取自己的資源，而不是存取某個使用者的資源」。適合的場景包括：
RFC 6749 對這個 Grant Type 有一個很明確的限制：
⚠️Client Credentials Grant 只能用在機密客戶端（Confidential Client）。因為整個流程的安全性完全建立在 client_secret 不外流上，SPA、原生 App 這類無法安全保存 Secret 的公開客戶端（Public Client）不該使用這個 Grant Type
跟前面幾篇動輒 7、8 個步驟的流程比起來，Client Credentials Grant 簡單很多。它不需要把使用者導向 Authorization Server，也不需要顯示同意畫面；Client 直接在後端向 Token Endpoint 請求 Access Token。
RFC 原文特別解釋了為什麼這麼簡單：「Since the client authentication is used as the authorization grant, no additional authorization request is needed.」——因為 Client 驗證自己身份的過程，本身就同時扮演了 Authorization Grant 的角色，所以不需要像 Authorization Code Grant 那樣，先繞去授權端點走一輪使用者同意，才能到 Token Endpoint 換票。
流程可以拆成下面幾步：
這張圖也可以用來理解 Machine-to-Machine（M2M）應用：M2M App 本質上就是一個用自己身份呼叫 API 的 Client application，而不是代表某位使用者操作。
下一篇會介紹的 Device Authorization Grant 則仍然有使用者參與，只是登入與授權會改在手機或電腦等另一台裝置上完成。
💡Resource Server 仍然要照樣驗證 Access Token、執行存取控制策略——Client Credentials Grant 省略的只是「向使用者要授權」這一步，不代表 Resource Server 這端可以少驗證。
一個典型的 Token 請求長這樣（範例來自 Logto Auth Wiki）:
POST /token HTTP/1.1
Host: your-authorization-server.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&scope=read write
| 參數 | 說明 |
|---|---|
grant_type |
固定設為 client_credentials |
client_id |
Authorization Server 核發的 Client 識別碼 |
client_secret |
Authorization Server 核發的 Client 密鑰 |
scope |
請求的權限範圍 |
resource |
選用，指定目標資源（需要 Authorization Server 支援 RFC 8707） |
實務上應該盡量限制 scope，只授予 Client 實際需要的權限。這點在 Client Credentials Grant 特別重要，因為這顆 Token 代表的是應用程式本身；一旦權限開得太大，外洩時的影響範圍通常會比單一使用者 Token 更廣。
回應格式跟其他 Grant Type 一樣遵守 RFC 6749 §5.1，但有一個關鍵差異——RFC 原文寫得很直白：「A refresh token SHOULD NOT be included.」因為 Client 隨時都可以用自己的憑證再要一個新的 Access Token，沒有必要額外核發 Refresh Token，這反而只是多一個可能被盜用的風險面。
Client 身份驗證的方式也不是只有把 client_secret 放進 request body 一種。以 Spotify 為例，它要求把 client_id 和 client_secret 做 Base64 編碼後放進 Authorization 標頭:
Authorization: Basic <base64 encoded client_id:client_secret>
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
回應則是:
{
"access_token": "NgCXRKc...MzYjw",
"token_type": "bearer",
"expires_in": 3600
}
兩種帶憑證的方式（body 參數 vs. Basic Auth 標頭）都是 RFC 6749 §2.3.1 允許的 Client 身份驗證方法，實務上用哪一種取決於 Authorization Server 支援什麼。
前面講的是 Client Credentials Grant 的通用流程；如果放到企業身份平台裡，Microsoft Entra ID 是一個很典型的例子。它常把這類流程稱為 two-legged OAuth，意思是流程中主要只有兩方在互動：應用程式本身，以及負責核發 Token 的 Authorization Server。
在 Microsoft Entra ID 裡，這裡最重要的是先分清楚兩種權限：
Client Credentials Grant 沒有使用者參與，所以在 Microsoft Entra ID 這種企業場景中，通常會對應到 Application Permissions。也就是說，Access Token 代表的是應用程式本身被授予的權限。
以上圖來看，流程可以理解成：
client_id、client_secret 與 grant_type=client_credentials，向 Token 端點請求 Access Token。這也是為什麼 Microsoft Entra ID 常會使用 /.default 這種 Scope 寫法。它不是像一般使用者授權流程那樣，在登入時一項一項要求使用者同意；而是表示「使用這個應用程式事先被管理員核准的那些權限」。例如 https://graph.microsoft.com/.default，就是要求 Microsoft Graph 根據這個應用程式已被核准的權限來核發 Token。
除了 client_secret，Microsoft Entra ID 也支援用憑證（Certificate）驗證 Client 身份。這些方式比單純使用共享密鑰更適合企業環境，因為可以降低密鑰外洩的風險。
實作 Client Credentials Grant 時有幾個重點：
Client Credentials Grant 解決的是「沒有使用者參與時，Client 要怎麼取得授權」的問題，常見於後端服務、自動化程式、排程工作、微服務或企業內部系統之間的 API 呼叫。
它和 Authorization Code Grant 最大的差異在於：這裡沒有使用者登入，也沒有使用者同意畫面。Client 會直接用自己的身分向 Authorization Server 請求 Access Token，取得的 Token 代表的是應用程式本身。
最後整理成三件事：
client_secret 或憑證不能外洩，所以 SPA、手機 App 這類公開客戶端不適合使用。下一篇會回到「有使用者參與」的情境，但裝置本身不一定適合輸入帳密或接收瀏覽器重新導向。這就是 Device Authorization Grant 要解決的問題：讓使用者改用手機或電腦完成登入與授權，原本的裝置再取得 Access Token。
iThome鐵人賽
看影片追技術