微服務(或API)的用戶身分驗證

最近不只一次被問到這個問題。

在應用程式(或前端展示層App)呼叫API(或微服務)的時候, 雖然都會有攜帶API KEY來驗證呼叫者(App)的身分,但若是要知道用戶的身分(就是誰操作這個App來呼叫API的?),又該怎麼辦呢?

一般來說,當我們討論微服務開發時,大多不一定會包含UI(套句Uncle Bob說的,UI是細節)。因此,在實作用戶端(End-User)的身分驗證時,往往只會做到UI(展示層)為止。但實務上,不管是多層式架構或是微服務架構,UI(展示層)又會需要呼叫微服務(或應用層API)來實現系統功能。

像是底下這樣:
圖片

但在UI呼叫微服務(應用層API)時,被呼叫端需要確認呼叫端(UI/展示層)具有呼叫微服務(或API)的權限,這一段,大多只會採用API KEY來驗證。

例如:

POST /APIName HTTP/1.1
Host: domain.com
Content-Type: application/json
ApiKey: 3126616e-c14b-4ba8-8617-d7349541ce40
Content-Length: 23

{"data" : "infomation"}

然而,若某些微服務(或API)運作時還需要得知用戶端身分,又會怎麼做呢?

簡單一點的作法,是直接透過JSON Body告知API當前用戶是誰(前提當然是API信任這個呼叫端),這樣既暴力又簡單,如果想更嚴謹一點,可以在Header攜帶先前用戶已經驗證過的Access Token/JWT Token來實現:

UserWeb App (UI)Microservices(API)登入(Cookies/JWT/OAuth)登入成功(保留User Token)...若不須用戶身分資訊...發送請求呼叫API (帶上API Key)(API確認呼叫者是哪個App)返回結果顯示結果...當需要用戶身分資訊...發送請求(帶上User Token)呼叫API (帶上API Key, User Token)(API確認呼叫者是哪個App, 哪位User)返回結果顯示結果UserWeb App (UI)Microservices(API)

但如此一來,微服務(或API)就必須具備解析Token的能力,或是再拿Token去問身分查驗的服務)。這樣不僅僅可以知道是哪個APP呼叫自己,也能得知是哪一個用戶操作這個APP來呼叫自己(上圖最底下的部分)。

總的來說,API KEY和User Token是兩個不同的機制(別搞混了),API KEY只用做用戶端對伺服器端的驗證,也就是呼叫者(這個APP或UI)的驗證,而OAuth Access Token或JWT Token則用作用戶端身分的驗證,兩者的目的並不相同。


相關教育訓練:
https://www.studyhost.tw/NewCourses/Architecture
https://www.studyhost.tw/NewCourses/aspnetcoreauth

若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

留言

這個網誌中的熱門文章

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

VS Code的字體大小

使用 Dify 建立企業請假機器人

使用Qdrant向量資料庫實作語意相似度比對

使用C#開發LineBot(3) - 使用LineBotSDK發送Line訊息