本系列文之後也会置於个人网站

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(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