做者:Allen
版權:轉載請在文章明顯位置註明做者及出處。如發現錯誤,歡迎批評指正。
上一節講到如何在咱們的項目中集成Azure AD 保護咱們的API資源,以及在項目中集成Swagger,而且如何把Swagger做爲一個客戶端進行認證和受權去訪問咱們的WebApi資源的?本節就接着講如何在咱們的項目中集成 Azure AD 保護咱們的API資源,使用其餘幾種受權模式進行受權認證,好了,開始今天的表演。🎉🎉🎉🎉🎉git
上一篇結尾咱們成功的拿到了 access_token,而且經過 access_token 驗證獲取到調用Api資源的結果。咱們先從swagger中去複製access_token,如圖所示:github
而後去 JWT.IO 解析 tokenapi
如下是解析出的所有內容,牽扯到我的隱私的內容,以使用 ‘x’ 符號代替,還請見諒服務器
{ "aud": "f38ec09d-203e-4b2d-a1c1-faf76a608528", "iss": "https://sts.chinacloudapi.cn/53359126-8bcf-455d-a934-5fe72d349207/", "iat": 1589374088, "nbf": 1589374088, "exp": 1589377988, "acr": "1", "aio": "AUQAu/8HAAAABTQ0iHchtR+GpkOehfH2AYXoIa0tBYg0sf1atq88824rp/+ucL2LpSdCZB8SvLbZ7dpzxUh/BUThEiz5r05COg==", "amr": [ "pwd" ], "appid": "62ca9f31-585c-4d28-84b6-25fb7855aed0", "appidacr": "0", "email": "xxx@xxx.partner.onmschina.cn", "family_name": "xxx", "given_name": "xxx@xxx.partner.onmschina.cn", "idp": "https://sts.chinacloudapi.cn/71c1d8b2-6eec-4ae9-8671-208667b351c9/", "ipaddr": "113.201.51.xxx", "name": "xxx@xxx.partner.onmschina.cn yun", "oid": "0f7b8378-d133-4d76-8e5c-daf93a553b6e", "scp": "Order.Read", "sub": "-FvDwjpV6m3ZHBCC-MePlP-iSqmHi39_s5wvTCagThU", "tid": "53359126-8bcf-455d-a934-5fe72d349207", "unique_name": "xxx@xxx8.partner.onmschina.cn", "uti": "V1-3tIF2nEWUH7CH1FkOAA", "ver": "1.0" }
從這些信息不難看到,令牌的頒發者,頒發時間,失效時間,客戶端Id等等信息app
着重看如下這幾個參數:post
1,aud(audience):聽衆。這裏直譯起來比較拗口,其實說白了,就是這個令牌用於誰,使用令牌去訪問誰,誰就是audience。學習
2,iss(Issuer):頒發者。是隻誰頒發的這個令牌,很顯眼就咱們azure認證的一個域在加上咱們建立的這個租戶測試
3,iat:令牌頒發時間spa
4,exp:令牌過時時間,與上面的頒發時間相差5分鐘3d
5,appid:客戶端Id,就是在Azure AD裏面給Swagger註冊的客戶端應用的Id
6,scp:權限範圍,咱們爲Swagger受權訪問WebApi的權限
看到這裏,是否是感受和 Identity Server 4受權驗證中心的好多配置特別類似。是的,這裏也不要感受到奇怪,Azure AD 也是基於OAuth 2.0和Open Id Connect協議的一種認證受權體系。只要有了 Identity Server 4的一些基礎,學習Azure AD的這套認證受權也是很好入手的。
Resource Owner其實就是User,密碼模式相較於客戶端憑證模式,多了一個參與者,就是User。經過User的用戶名和密碼向認證中心申請訪問令牌。
按照慣例,在postman中直接進行調用order的接口。
ResponseCode:401,提示沒有權限。
1)爲WebApi應用建立客戶端密碼
選擇過時時間,點擊 」添加「
複製這個密碼的值,提示如下,切換到其餘頁面後,就沒法再進行復制了,全部提早先複製好。
2)查看資源全部者
選擇 管理=》全部者 打開資源全部者頁面
圖上顯示已經有一個全部者帳號,有人就問了,本身明明沒有添加任何全部者信息,爲何就憑空冒出來一個全部者帳號。其實不難看出,這個帳號就是咱們當前azure portal的登陸帳號,也是當前訂閱的管理員帳號,並且咱們在建立MyCommany這個租戶的時候也是使用的當前登陸的帳號,全部當前登陸的帳號也就天然而然的成爲當前租戶下應用註冊的資源全部者。
3)查看WebApi的做用域
選擇 管理=》公開 API
複製 WebApi的做用域
4)查看WebApi的終結點
複製當前應用程序的 OAuth 2.0令牌終結點(v2)連接,注意圈起來的 organization 參數,這個須要換成當前應用程序所在的租戶的Id。
5)測試
1)統一驗證,獲取token
tenant:應用程序計劃對其進行操做的目錄租戶。參數必傳
client_id:分配給應用的應用程序ID,能夠在註冊應用的門戶中找到。參數必傳。
scope:在此請求中針對 scope參數傳遞的值應該是所需資源的資源標識符。參數可選。
client_secret:在應用註冊門戶中爲應用生成的客戶端機密。參數必傳
grant_type:必須設置爲 password。參數必傳
username:用戶的電子郵件地址
password:用戶的密碼
2)訪問 api/order
砰,成功!此處應該有掌聲🎉🎉🎉🎉🎉,成功的經過驗證,而且獲取到 api資源,可是這種模式是最不推薦的,由於client可能存了用戶密碼,此模式僅用於受信任的客戶端。複製會發生密碼泄露。因此不推薦使用。
固然,咱們也會根據實際項目的狀況選擇不一樣的受權模式。👇
客戶端憑證模式,是最簡單的受權模式,由於受權的流程僅發生在客戶端和受權認證中心之間。適用場景爲服務器與服務器之間的通訊。
1)統一驗證,獲取token,須要額外注意此處的租戶Id,以及scope
tenant:應用程序計劃對其進行操做的目錄租戶。參數必傳
client_id:分配給應用的應用程序ID,能夠在註冊應用的門戶中找到。參數必傳。
scope:在此請求中針對 scope參數傳遞的值應該是所需資源的資源標識符。參數必傳。
client_secret:在應用註冊門戶中爲應用生成的客戶端機密。參數必傳
grant_type:必須設置爲 client_credentials。參數必傳
這時候,就又有人問了,爲何這裏的 scope 參數的值和上面不同,確實,我也有這個疑問,後來找到微軟官方給個人文檔解釋道:
在此請求中針對 scope
參數傳遞的值應該是所需資源的資源標識符(應用程序 ID URI),並附有 .default
後綴。 在 Microsoft Graph 示例中,該值爲 https://graph.microsoft.com/.default
。
此值告知 Microsoft 標識平臺終結點:在爲應用配置的全部直接應用程序權限中,終結點應該爲與要使用的資源關聯的權限頒發令牌
使用共享機密訪問令牌請求:https://docs.microsoft.com/zh-cn/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
2)訪問 api/order
砰,成功,再次撒花祝賀,🎉🎉🎉🎉🎉!這種模式直接是經過 client id 和 client secret 來獲取 access_token,該方法一般用於服務器之間的通信
以上就是使用 資源持有者密碼受權以及 客戶端憑據受權兩種受權模式。到此 關於ASP.NET Core Web Api 集成 Azure AD 的受權認證暫時告一段落。
今天的文章大概介紹了若是在咱們的項目中集成 Azure AD,以及如何使用 Resource Owner Password Credentials(資源持有者密碼認證)和Client Credentials(客戶端憑證)
下一篇繼續介紹 Azure AD B2C 的相關內容。
github:https://github.com/allentmater/Azure.AD.WebApi.git
做者:Allen
版權:轉載請在文章明顯位置註明做者及出處。如發現錯誤,歡迎批評指正。