Azure AD（二）呼叫受Microsoft 標識平臺保護的 ASP.NET Core Web API 下

Grant_Allen發表於2020-05-14

一，引言

　　上一節講到如何在我們的專案中整合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