一，引言
上一節講到如何在我們的項目中集成Azure AD 保護我們的API資源，以及在項目中集成Swagger，並且如何把Swagger作為一個客戶端進行認證和授權去訪問我們的WebApi資源的？本節就接着講如何在我們的項目中集成 Azure AD 保護我們的API資源，使用其他幾種授權模式進行授權認證，好了，開始今天的表演。🎉🎉🎉🎉🎉
二，正文
1，access_token的剖析！
上一篇結尾我們成功的拿到了 access_token，並且通過 access_token 驗證獲取到調用Api資源的結果。我們先從swagger中去復制access_token，如圖所示：
然后去 JWT.IO 解析 token
以下是解析出的全部內容，牽扯到個人隱私的內容，以使用 ‘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等等信息
着重看以下這幾個參數：
1，aud（audience）：聽眾。這里直譯起來比較拗口，其實說白了，就是這個令牌用於誰，使用令牌去訪問誰，誰就是audience。
2，iss（Issuer）：頒發者。是只誰頒發的這個令牌，很顯眼就我們azure認證的一個域在加上我們創建的這個租戶
3，iat：令牌頒發時間
4，exp：令牌過期時間，與上面的頒發時間相差5分鍾
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的這套認證授權也是很好入手的。
2，使用 Resource Owner Password Credentials 訪問 API 資源
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可能存了用戶密碼，此模式僅用於受信任的客戶端。復制會發生密碼泄露。所以不推薦使用。
當然，我們也會根據實際項目的情況選擇不同的授權模式。👇
3，使用 Client Credentials 訪問資源
客戶端憑證模式，是最簡單的授權模式，因為授權的流程僅發生在客戶端和授權認證中心之間。適用場景為服務器與服務器之間的通信。
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/yunqian44/Azure.AD.WebApi.git
作者：Allen
版權：轉載請在文章明顯位置注明作者及出處。如發現錯誤，歡迎批評指正。