一，引言

　　上一節(jié)講到如何在我們的項目中集成Azure AD 保護我們的API資源，以及在項目中集成Swagger，并且如何把Swagger作為一個客戶端進行認證和授權(quán)去訪問我們的WebApi資源的？本節(jié)就接著講如何在我們的項目中集成 Azure AD 保護我們的API資源，使用其他幾種授權(quán)模式進行授權(quán)認證，好了，開始今天的表演。????????????????????

二，正文

1，access_token的剖析！

　　上一篇結(jié)尾我們成功的拿到了 access_token，并且通過 access_token 驗證獲取到調(diào)用Api資源的結(jié)果。我們先從swagger中去復(fù)制access_token，如圖所示：

?然后去?JWT.IO? 解析 token

?

?

?以下是解析出的全部內(nèi)容，牽扯到個人隱私的內(nèi)容，以使用 ‘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" }

從這些信息不難看到，令牌的頒發(fā)者，頒發(fā)時間，失效時間，客戶端Id等等信息

著重看以下這幾個參數(shù)：

　　1，aud（audience）：聽眾。這里直譯起來比較拗口，其實說白了，就是這個令牌用于誰，使用令牌去訪問誰，誰就是audience。

　　2，iss（Issuer）：頒發(fā)者。是只誰頒發(fā)的這個令牌，很顯眼就我們azure認證的一個域在加上我們創(chuàng)建的這個租戶

3，iat：令牌頒發(fā)時間

4，exp：令牌過期時間，與上面的頒發(fā)時間相差5分鐘

5，appid：客戶端Id，就是在Azure AD里面給Swagger注冊的客戶端應(yīng)用的Id

6，scp：權(quán)限范圍，我們?yōu)镾wagger授權(quán)訪問WebApi的權(quán)限

看到這里，是不是感覺和 Identity Server 4授權(quán)驗證中心的好多配置特別相似。是的，這里也不要感覺到奇怪，Azure AD 也是基于OAuth 2.0和Open Id Connect協(xié)議的一種認證授權(quán)體系。只要有了?Identity Server 4的一些基礎(chǔ)，學(xué)習(xí)Azure AD的這套認證授權(quán)也是很好入手的。

2，使用?Resource Owner Password Credentials 訪問 API 資源

　　Resource Owner其實就是User，密碼模式相較于客戶端憑證模式，多了一個參與者，就是User。通過User的用戶名和密碼向認證中心申請訪問令牌。

　　按照慣例，在postman中直接進行調(diào)用order的接口。

?ResponseCode:401,提示沒有權(quán)限。

1）為WebApi應(yīng)用創(chuàng)建客戶端密碼

?

?

?選擇過期時間，點擊 ”添加“?

?復(fù)制這個密碼的值，提示以下，切換到其他頁面后，就無法再進行復(fù)制了，所有提前先復(fù)制好。

2）查看資源所有者

　　選擇 管理=》所有者 打開資源所有者頁面

圖上顯示已經(jīng)有一個所有者賬號，有人就問了，自己明明沒有添加任何所有者信息，為什么就憑空冒出來一個所有者賬號。其實不難看出，這個賬號就是我們當前azure portal的登錄賬號，也是當前訂閱的管理員賬號，而且我們在創(chuàng)建MyCommany這個租戶的時候也是使用的當前登錄的賬號，所有當前登錄的賬號也就自然而然的成為當前租戶下應(yīng)用注冊的資源所有者。

3）查看WebApi的作用域

　　選擇 管理=》公開 API

?復(fù)制 WebApi的作用域

4）查看WebApi的終結(jié)點

?復(fù)制當前應(yīng)用程序的 OAuth 2.0令牌終結(jié)點(v2)鏈接，注意圈起來的 organization 參數(shù)，這個需要換成當前應(yīng)用程序所在的租戶的Id。

5）測試

　　1）統(tǒng)一驗證，獲取token

　　　　tenant：應(yīng)用程序計劃對其進行操作的目錄租戶。參數(shù)必傳

　　　　client_id：分配給應(yīng)用的應(yīng)用程序ID，可以在注冊應(yīng)用的門戶中找到。參數(shù)必傳。

　　　　scope：在此請求中針對?scope參數(shù)傳遞的值應(yīng)該是所需資源的資源標識符。參數(shù)可選。

　　　　client_secret：在應(yīng)用注冊門戶中為應(yīng)用生成的客戶端機密。參數(shù)必傳

　　　　grant_type：必須設(shè)置為 password。參數(shù)必傳

　　　　username：用戶的電子郵件地址

　　　　password：用戶的密碼

?

?　　2）訪問 api/order

?砰，成功！此處應(yīng)該有掌聲????????????????????，成功的通過驗證，并且獲取到 api資源，但是這種模式是最不推薦的，因為client可能存了用戶密碼，此模式僅用于受信任的客戶端。復(fù)制會發(fā)生密碼泄露。所以不推薦使用。

當然，我們也會根據(jù)實際項目的情況選擇不同的授權(quán)模式。????

?3，使用 Client Credentials 訪問資源

　　?客戶端憑證模式，是最簡單的授權(quán)模式，因為授權(quán)的流程僅發(fā)生在客戶端和授權(quán)認證中心之間。適用場景為服務(wù)器與服務(wù)器之間的通信。

　　1）統(tǒng)一驗證，獲取token，需要額外注意此處的租戶Id，以及scope

　　　　tenant：應(yīng)用程序計劃對其進行操作的目錄租戶。參數(shù)必傳

　　　　client_id：分配給應(yīng)用的應(yīng)用程序ID，可以在注冊應(yīng)用的門戶中找到。參數(shù)必傳。

　　　　scope：在此請求中針對?scope參數(shù)傳遞的值應(yīng)該是所需資源的資源標識符。參數(shù)必傳。

　　　　client_secret：在應(yīng)用注冊門戶中為應(yīng)用生成的客戶端機密。參數(shù)必傳

　　　　grant_type：必須設(shè)置為 client_credentials。參數(shù)必傳

?　

?

?這時候，就又有人問了，為什么這里的 scope 參數(shù)的值和上面不一樣，確實，我也有這個疑問，后來找到微軟官方給我的文檔解釋道：

?Microsoft Graph 示例中，該值為?https://graph.microsoft.com/.default。

此值告知 Microsoft 標識平臺終結(jié)點：在為應(yīng)用配置的所有直接應(yīng)用程序權(quán)限中，終結(jié)點應(yīng)該為與要使用的資源關(guān)聯(lián)的權(quán)限頒發(fā)令牌

使用共享機密訪問令牌請求：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，該方法通常用于服務(wù)器之間的通訊

?

以上就是使用 資源持有者密碼授權(quán)以及 客戶端憑據(jù)授權(quán)兩種授權(quán)模式。到此 關(guān)于ASP.NET Core Web Api 集成 Azure AD 的授權(quán)認證暫時告一段落。

三，結(jié)尾

今天的文章大概介紹了如果在我們的項目中集成 Azure AD，以及如何使用 Resource Owner Password Credentials（資源持有者密碼認證）和Client Credentials（客戶端憑證）?

下一篇繼續(xù)介紹 Azure AD B2C 的相關(guān)內(nèi)容。

github:https://github.com/allentmater/Azure.AD.WebApi.git

作者：Allen?

版權(quán)：轉(zhuǎn)載請在文章明顯位置注明作者及出處。如發(fā)現(xiàn)錯誤，歡迎批評指正。

作者：Allen 版權(quán)：轉(zhuǎn)載請在文章明顯位置注明作者及出處。如發(fā)現(xiàn)錯誤，歡迎批評指正。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的【壹刊】Azure AD 保护的 ASP.NET Core Web API （下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。