本系列文之後也會置於個人網站

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

                     Figure 6: Client Credentials Flow

嘗試 Client Credentials flow

Client Credentials，這個模式有點特別。除了前面看到的它可能與其他模式並用以外，最特別的是，單純使用它，完全不需要資源擁有者參予。總之先來看看：

你可以使用RESTfer嘗試看看：

grant_type: client_credentials
client_id: oauth_tools
client_secret: <之前所產生的secret>

或是同樣可以透過OAuth.Tools嘗試看看。

與之前相同，OAuth.Tools可能無法與我們建立的授權伺服器溝通，所以需要複製Curl的命令：

python -m json.tool <(curl -Ss -X POST http://localhost:8080/auth/realms/quick-start/protocol/openid-connect/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=client_credentials&client_id=oauth_tools&client_secret=7d087013-4059-4cdc-814c-e925c1596d24')

細看Client Credentials

你可以發現這次的返回值與隱含模式同樣沒有refresh_token。這是因爲在配置時client_secret應該只能由客戶端擁有，不會送到瀏覽器參予前端通訊，且你會注意到在這次中同樣不存在前端通訊，甚至不知道資源擁有者是誰(之前使用bob帳號登入)。

因爲按理client_secret只有客戶端擁有，所以其實客戶端可以隨時取得access_token。就像是爲客戶端建立一個系統帳號，client_id 就是帳號；而client_secret就是密碼。

實際上也確實是如此，你可以在設定client的頁面將Authorization Enabled和Service Accounts Enabled關閉。這麼一來就無法使用該模式了。

雖然之後還會提到JWT，但Client Credentials篇幅可能不會太多。所以先來使用JWT.io來看看access_token。

在分析完access_token後，雖然重要的其實是sub，但preferred_username更可以看出這是一個特殊帳號：

另外可以透過 Service Account Roles 頁籤來設定該帳號所擁有的角色。按照設計，這有可能像是在「深入OAuth 2.0」所提到的 開發者權杖 。

參考資料

• OAuth 2.0 實戰
• RFC6749