在 Azure 中提供了各式各樣的 API 讓我們可以在不同的場景中隨意組合使用,對於服務的 API 一般會在建立完成時分配一個專用的 Key,雖然這可能不是最佳作法,但直接使用 Key 來呼叫 API 的作法非常方便直觀。然而其他非服務類或管理層面的 API 就會遵循 OAuth 2.0 標準來設計,這對於初次使用且不太熟悉 OAuth 2.0 流程的人來說就不是很好上手。
這篇文章就來記錄一下如何在 Service Principal 中使用 OAuth 2.0 四個基礎流程之一的 Client Credentials 來呼叫 Azure API,並且盡量跳過那些繁雜的 OAuth 2.0 理論。
建立 Service Principal
首先建立要用來呼叫 API 的 Service Principal,使用以下 Azure CLI 指令:
指令在建立時會順便指派權限給 Service Principal,以這邊為例,我們將 Service Principal 指派在資源群組範圍 "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/charlie-test" 上的 Reader。
建立成功後會得到以下回應:
其中 appId、password 與 tenant 會在下一步中使用,記得要先記錄下來。
另外在 Portal 中的 Microsoft Entra ID 也可以搜尋得到建立完成的 Service Principal。
取得 Access Token
在上一步中我們得到了類似密碼或 Key 的 password,但這並不能直接作為呼叫 API 的驗證,我們必須要先用這個 password 來換取 Access Token。
至於為什麼需要多這一步驟,就與最一開始提到 OAuth 2.0 的 Client Credentials 有關,我們將理論的部分留給有興趣的讀者,現在我們只要把他當成固定流程就好。
取得 Access Token 的方式是一個 HTTP Post,以下我們選擇可以直接在 Azure Cloud Shell 中執行的 curl 指令作為範例。
其中 <TENANT-ID>、<APP-ID> 與 <PASSWORD> 使用上一步紀錄下來的資訊填入即可。
執行成功後會得到以下類似回應:
其中的 access_token 就可以作為呼叫 API 的驗證了。
呼叫 API
我們使用資源群組的 List API 作為範例,規格文件請查看以下連結。
不要忘記將 <ACCESS-TOKEN> 替換為上一步得到的 access_token。
執行成功後會得到以下類似回應:
因為在最一開始建立 Service Principal 時,我們只賦予了 charlie-test 這個資源群組的 Reader 權限,所以這個範例只列出一個資源群組是正確的👍
總結
使用 Service Principal 搭配 Client Credentials 適合使用在不需要用戶交互的應用程式中,算是 OAuth 2.0 中相對簡單的流程,像我自己就常使用在一些背景執行的監控管理排程上。
另外本篇文章也盡量去除掉理論,只留下實作流程,也推薦給只想快速測一下 API 的讀者 😄
留言
張貼留言