Azure 應用服務和 Azure Functions 中的身份驗證和授權,azure創(chuàng)建博客-ESG跨境

Azure 應用服務和 Azure Functions 中的身份驗證和授權,azure創(chuàng)建博客

Azure 應用服務和 Azure Functions 中的身份驗證和授權

Azure應用服務提供內置的身份驗證和授權支持。只需在Web應用、RESTful API、移動后端和Azure Functions中編寫少量的代碼或根本無需編寫代碼，就能讓用戶登錄和訪問數(shù)據(jù)。本文介紹應用服務如何幫助簡化應用的身份驗證和授權。

安全身份驗證和授權需要對安全性（包括聯(lián)合身份驗證、加密、JSON Web令牌(JWT)管理、授權類型等）有深度的了解。應用服務提供這些實用工具，讓你將更多的時間和精力花費在為客戶提供業(yè)務價值上。

重要

你并非必須使用此功能進行身份驗證和授權?？梢栽谒x的Web框架中使用捆綁的安全功能，也可以編寫自己的實用程序。但請記住，Chrome 80針對Cookie對其實現(xiàn)SameSite的方式進行了中斷性變更（發(fā)布日期在2020年3月左右）；自定義遠程身份驗證或依賴于跨站點Cookie發(fā)布的其他方案可能會在客戶端Chrome瀏覽器更新時中斷。解決方法很復雜，因為需要針對不同的瀏覽器支持不同的SameSite行為。

應用服務托管的ASP.NET Core 2.1及更高版本已針對此中斷性變更進行了修補，并且會相應地處理Chrome 80和更低版本的瀏覽器。此外，我們還在整個2020年1月在應用服務實例上部署了ASP.NET Framework 4.7.2的同一修補程序。有關詳細信息，請參閱Azure應用服務SameSite Cookie更新。

備注

“身份驗證/授權”功能有時也稱為“簡單身份驗證/授權”。

備注

啟用此功能會導致對應用程序的所有非安全HTTP請求自動重定向到HTTPS，而不管強制實施HTTPS所需的應用服務配置設置如何。如果需要，可以通過身份驗證/授權設置配置文件中的requireHttps設置禁用此功能，但需注意確保不通過非安全HTTP連接傳輸安全令牌。

有關特定于本機移動應用的信息，請參閱使用Azure應用服務對移動應用進行用戶身份驗證和授權。

工作原理

在Windows上

身份驗證和授權模塊在應用程序代碼所在的同一沙盒中運行。啟用后，每個傳入的HTTP請求將通過此模塊，然后由應用程序代碼處理。

一個體系結構圖，顯示請求被站點沙盒中的進程攔截，該進程與標識提供者進行交互，然后再允許流量發(fā)往已部署的站點

此模塊為應用處理多項操作：

·使用指定的提供程序對用戶進行身份驗證

·驗證、存儲和刷新令牌

·管理經(jīng)過身份驗證的會話

·將標識信息插入請求標頭

此模塊獨立于應用程序代碼運行，使用應用設置進行配置。不需要任何SDK、特定語言，或者對應用程序代碼進行更改。

用戶/應用程序聲明

對于所有語言框架，應用服務都通過將傳入令牌（無論是來自經(jīng)過身份驗證的最終用戶還是來自客戶端應用程序）中的聲明注入請求標頭，使其可供代碼使用。對于ASP.NET 4.6應用，應用服務會在ClaimsPrincipal.Current中填充經(jīng)過身份驗證的用戶聲明，使你能夠遵循標準的.NET代碼模式（包括[Authorize]屬性）。同樣，對于PHP應用，應用服務會填充SERVER[REMOTEUSER]變量。對于Java應用，可從Tomcat servlet訪問聲明。

對于Azure Functions，沒有為.NET代碼填充ClaimsPrincipal.Current，但你仍然可以在請求標頭中找到用戶聲明，也可通過請求上下文甚至通過綁定參數(shù)來獲取ClaimsPrincipal對象。有關詳細信息，請參閱使用客戶端標識。

有關詳細信息，請參閱訪問用戶聲明。

備注

目前，ASP.NET Core不支持為當前用戶填充身份驗證/授權功能。但是，確實存在一些第三方開源中間件組件，可以幫助填補這一空白。

令牌存儲

應用服務提供內置的令牌存儲，這是與Web應用、API或本機移動應用的用戶相關聯(lián)的令牌存儲庫。對任何提供程序啟用身份驗證時，此令牌存儲可立即供應用使用。如果應用程序代碼需要代表用戶訪問這些提供程序中的數(shù)據(jù)，例如：

發(fā)布到經(jīng)過身份驗證用戶的MicrosoftAccount時間線

使用Microsoft Graph API讀取用戶的公司數(shù)據(jù)

通常，必須編寫代碼才能在應用程序中收集、存儲和刷新這些令牌。使用令牌存儲，只需在需要令牌時才檢索令牌；當令牌失效時，可以告知應用服務刷新令牌。

將為經(jīng)身份驗證的會話緩存ID令牌、訪問令牌和刷新令牌，它們只能由關聯(lián)的用戶訪問。

如果不需要在應用中使用令牌，可以在應用的“身份驗證/授權”頁中禁用令牌存儲。

日志記錄和跟蹤

如果啟用應用程序日志記錄，將在日志文件中直接看到身份驗證和授權跟蹤。如果出現(xiàn)意外的身份驗證錯誤，查看現(xiàn)有的應用程序日志即可方便找到所有詳細信息。如果啟用失敗請求跟蹤，可以確切地查看身份驗證和授權模塊在失敗請求中發(fā)揮的作用。在跟蹤日志中，找到對名為EasyAuthModule32/64的模塊的引用。

標識提供者

應用服務使用聯(lián)合標識，在其中，第三方標識提供者會為你管理用戶標識和身份驗證流。默認提供五個標識提供者：

對其中一個提供程序啟用身份驗證和授權時，其登錄終結點可用于用戶身份驗證，以及驗證來自提供程序的身份驗證令牌?？梢暂p松為用戶提供其中任意數(shù)量的登錄選項。

存在舊版可擴展性路徑，用于與其他標識提供者或自定義身份驗證/授權解決方案集成，但是不建議使用，而應考慮使用OpenID Connect支持。

身份驗證流

身份驗證流對于所有提供程序是相同的，但根據(jù)是否要使用提供程序的SDK登錄而有所差別：

·不使用提供程序SDK：應用程序向應用服務委托聯(lián)合登錄。瀏覽器應用通常采用此方案，這可以防止向用戶顯示提供程序的登錄頁。服務器代碼管理登錄過程，因此，此流也稱為“服務器導向流”或“服務器流”。此方案適用于瀏覽器應用。它也適用于使用移動應用客戶端SDK登錄用戶的本機應用，因為SDK會打開Web視圖，使用應用服務身份驗證將用戶登錄。

·使用提供程序SDK：應用程序手動將用戶登錄到提供程序，然后將身份驗證令牌提交給應用服務進行驗證。無瀏覽器應用通常采用此方案，這可以防止向用戶顯示提供程序的登錄頁。應用程序代碼管理登錄過程，因此，此流也稱為“客戶端導向流”或“客戶端流”。此方案適用于REST API、Azure Functions和JavaScript瀏覽器客戶端，以及在登錄過程中需要更高靈活性的瀏覽器應用。它還適用于使用提供程序SDK登錄用戶的本機移動應用。

備注

對于應用服務中受信任瀏覽器應用對應用服務或Azure Functions中另一REST API的調用，可以使用服務器導向流對其進行身份驗證。有關詳細信息，請參閱在應用服務中自定義身份驗證和授權。

下表說明了身份驗證流的步驟。

對于客戶端瀏覽器，應用服務可自動將所有未經(jīng)身份驗證的用戶定向到/.auth/login/lt;providergt;。還可以向用戶提供一個或多個/.auth/login/lt;providergt;鏈接，讓他們使用所選的提供程序登錄到你的應用。

授權行為

在Azure門戶中，當傳入請求未經(jīng)過身份驗證時，可以使用多種行為配置應用服務授權。

一個屏幕截圖，顯示“請求未通過身份驗證時要采取的操作”下拉列表

以下標題介紹了選項。

允許匿名請求(無操作)

此選項將對未經(jīng)身份驗證的流量的授權交給應用程序代碼處理。對于經(jīng)過身份驗證的請求，應用服務還會在HTTP標頭中一起傳遞身份驗證信息。

使用此選項可以更靈活地處理匿名請求。例如，可以向用戶提供多個登錄提供程序。但是，必須編寫代碼。

僅允許經(jīng)過身份驗證的請求

選項是“使用provider登錄”。應用服務將所有匿名請求重定向到所選提供程序的/.auth/login/provider。如果匿名請求來自本機移動應用，則返回的響應為HTTP 401 Unauthorized。

使用此選項不需要在應用中編寫任何身份驗證代碼?？梢酝ㄟ^檢查用戶的聲明來處理精細授權，例如角色特定的授權（請參閱訪問用戶聲明）。

注意

以這種方式限制訪問適用于對應用的所有調用，對于想要主頁公開可用的應用程序來說，這可能是不可取的，就像在許多單頁應用程序中一樣。

備注

默認情況下，Azure AD租戶中的任何用戶都可以從Azure AD請求應用程序的令牌。若要僅允許一組定義的用戶訪問應用，可以在Azure AD中配置應用程序。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發(fā)表后的30日內與ESG跨境電商聯(lián)系。