iT邦幫忙

2021 iThome 鐵人賽

DAY 18
0
Software Development

用Keycloak學習身份驗證與授權系列 第 18

Day17 - 【概念篇】OAuth flows: Client Credentials

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


     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(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 EnabledService Accounts Enabled關閉。這麼一來就無法使用該模式了。


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

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

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

參考資料


上一篇
Day16 - 【概念篇】OAuth flows: Refresh Token
下一篇
Day18 - 【概念篇】OAuth flows: PKCE
系列文
用Keycloak學習身份驗證與授權40

尚未有邦友留言

立即登入留言