建站
咨詢
售后
建站咨詢
新聞中心
Azure活動目錄（Active Directory，Azure AD）是一種業(yè)界比較流行的企業(yè)級身份認證服務。如今，許多組織都在使用該服務，來啟用應用程序的單點登錄（SSO），并保護其提供的Web API。其中，基于OpenId Connect（OIDC）身份驗證的Microsoft Identity Platform 2.0是針對OAuth 2.0授權流程的最新改進版本。
站在用戶的角度思考問題，與客戶深入溝通，找到晉江網(wǎng)站設計與晉江網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站設計制作、網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、雅安服務器托管、企業(yè)郵箱。業(yè)務覆蓋晉江地區(qū)。
如果您的應用程序使用到了Azure AD的如下功能，那么本文正好向您介紹如何為多個Web API提供授權的方法：
1. 啟用單點登錄（OpenId Connect身份驗證）。
2. 使用OAuth 2授權（隱式授權流程）保護Web API。
3. 單個客戶端應用程序使用到了多個Web API提供程序。
首先，我們假設您的客戶端應用程序?qū)儆趩雾撁媸郊軜嫞⊿ingle Page Architecture，如：Angular SPA），而且該架構使用到了如下兩個不同的API：
1. Microsoft Graph API（https://dzone.com/articles/getting-access-token-for-microsoft-graph-using-oau?preview=true） - 獲取員工個人資料的詳細信息，并將其顯示在應用程序的GUI中。該過程需要獲取一個訪問令牌，并通過Graph API的調(diào)用進行提交。
2. 自定義的Web API – 服務于應用程序的基本功能和數(shù)據(jù)。對于每個Web API的調(diào)用，都必須獲得并提交不同的且單獨的訪問令牌。
顯然，應用程序的用戶必須事先使用Azure AD來進行身份驗證（OIDC，https://dzone.com/articles/integrating-okta-oauth-20-oidc-with-mulesoft-anypo），然后才能訪問受API保護的各項功能與數(shù)據(jù)。也就是說，它們需要傳遞有效的JWT訪問令牌，之后才能訪問到受保護的API。
在Azure Portal中執(zhí)行SPA應用程序的注冊
第一步，在Azure portal（https://portal.azure.com/#home）中注冊您的客戶端應用程序（SPA）。注意：請為您的SPA應用設置重定向的URI，并為隱式授權的OAuth 2數(shù)據(jù)流，選擇ID令牌和Access令牌。下圖是某個假定Web應用程序的屏幕截圖，可供您參考：
指定URI路由
在Azure Portal中公布Web API
為Web API定義如下的配置。
1. 為Web API自定義范圍，以控制其訪問受API保護的功能。
2. 授權可以調(diào)用Web API的客戶端應用程序，以實現(xiàn)在調(diào)用期間無需人工判斷是否同意。
公布API
在Azure Portal中為客戶端應用程序指定API的權限
為客戶端應用程序選擇調(diào)用API的所有權限。如果需要獲取用戶的配置文件，請選擇帶有User.Read的Microsoft Graph API。如下圖截屏所示：
請求Microsoft Graph API權限
用同樣的方法，選擇Web API、以及自定義API的權限范圍。
請求Web API權限
從Angular SPA中調(diào)用Microsoft Graph API
我們所假設的Angular SPA（https://dzone.com/articles/angular-tutorials-and-articles）會通過調(diào)用Graph API，來獲取用戶個人資料的詳細信息。當然，您也可以在Angular應用中使用任何一種身份驗證的客戶端庫，例如：
- angular-auth-oidc-client
- oidc-client
此處值得特別注意的是：Microsoft Graph API和自定義的Web API是兩個截然不同的API提供類型，因此它們的作用域是無法被組合到同一個Angular應用內(nèi)的同一個Azure AD進行授權調(diào)用的。那么，正確的方法應該是：使用兩個單獨的調(diào)用。即：分別對Microsoft Graph API和Web API各調(diào)用一次，并為每個調(diào)用指定不同的范圍。
下面是調(diào)用Microsoft Graph API的具體順序與步驟：
- 針對從Angular到Azure AD OAuth 2.0授權端點的首次調(diào)用，指定User.Read的范圍。
指定User.Read的范圍
2. Azure AD執(zhí)行用戶的身份驗證。
3. Azure AD生成訪問令牌，該訪問令牌能夠基于用戶配置文件的詳細信息，來調(diào)用Graph API的對應權限。同時，它還會生成一個ID令牌，以指示用戶進行登錄。
4. 注意：在v2.0中，Azure AD通過內(nèi)部調(diào)用userinfo Graph API，所獲取和返回的用戶詳細信息，僅為基本的用戶屬性。后續(xù)，我們可以顯式地調(diào)用另一個Graph API端點，以獲取用戶的詳細屬性信息。
5. 在Azure AD的重定向請求中，我們將基于Angular代碼，獲取對應的訪問令牌。通過調(diào)用Graph API，我們將此令牌的授權標頭（Authorization header）設置為Bearer類型的令牌。據(jù)此，API將返回用戶個人資料的詳細信息，包括：員工編號、照片和組織架構等。
如下示例是一個對于Graph API端點的HTTP GET請求，它能夠獲取用戶的員工編號。注意：Bearer類型的令牌應當在請求的授權標頭被傳遞過去。
https：//graph.microsoft.com/v1.0/me$,userPrincipalName,country,extension_8b4e685f580748b59864d62c2e7fcfad_employeeNumber
從Angular SPA中調(diào)用自定義的Web API
具體順序與步驟如下：
1. 指定http://mystatementapi/access_as_user的范圍（雖然可以是任意范圍，但是我們最好去匹配那些Azure AD portal中的應用程序，在其注冊過程中所定義好的范圍）。該范圍將被用于第二次調(diào)用Azure AD OAuth 2.0的授權端點。
指定user_as_access的范圍
2. 注意：由于在先前的調(diào)用中，我們的瀏覽器已經(jīng)設置好了身份驗證的cookie，因此這一步將不再執(zhí)行用戶的身份驗證。
3. Azure AD生成另一個具有訪問權限的訪問令牌，用以調(diào)用Web API。該令牌將被用于每一個Web API。
4. 在Azure AD重定向的請求中，我們將基于Angular代碼，獲取對應的訪問令牌。通過調(diào)用自定義的API，我們將此令牌的授權標頭（Authorization header）設置為Bearer類型的令牌。
5. Web API驗證來自Azure AD的令牌，如果驗證成功，則返回正常的響應信息；如果失敗，則告知有關錯誤的信息。
刷新訪問令牌
通常情況下，訪問令牌的有效期是短暫的。我們可以將令牌的過期時間配置為一個小時或更短。那么在令牌到期之前，客戶端應用程序應當從Azure AD處請求新的訪問令牌。而且，該過程應當在沒有用戶干預的情況，由后臺自動完成。因此，我們可以在客戶端應用程序中采用隱藏的iframe方法。
實際上，這對于用于調(diào)用那些自定義Web API的訪問令牌來說（而不是本示例前面提到的Graph API）顯然是必需的。
總結
上文提到的Azure AD充當了基于云端身份認證服務的角色，您完全可以將自己的應用部署到其他的云服務、或本地數(shù)據(jù)中心中，以實現(xiàn)個性化的身份驗證與授權。當然，在開始編寫Angular應用程序代碼之前，您也可以使用Postman客戶端（譯者注：一款強大的網(wǎng)頁調(diào)試和接口測試工具）來測試和驗證Azure AD的配置、以及各種Web API。
總的說來，通過上述詳細的設計方法和實現(xiàn)步驟，我們演示了Angular客戶端應用程序如何從不同的Web API處獲取OAuth 2類型授權的過程。希望對您有所幫助。
標題名稱：如何為多個WebAPI提供授權方法
URL網(wǎng)址：http://www.5511xx.com/article/cdpcgej.html
