原文：https://msdn.microsoft.com/zh-cn/magazine/dn781361.aspx

身份驗證和授權(quán)是應(yīng)用程序安全的基礎(chǔ)。身份驗證通過驗證提供的憑據(jù)來確定用戶身份，而授權(quán)則決定是否允許用戶執(zhí)行請求的操作。安全的 Web API 身份驗證基于確定的身份請求和授權(quán)用戶請求的資源訪問。

您可以在 ASP.NET Web API 中使用 ASP.NET Web API 管道中提供的擴展點，以及使用由主機提供的選項來實現(xiàn)身份驗證。對于 ASP.NET Web API 的第一個版本，常見的做法是使用授權(quán)篩選器或操作篩選器來實現(xiàn)身份驗證。ASP.NET Web API 2 引入了一個專門用于此過程的新的身份驗證篩選器。這種新的擴展點使身份驗證和授權(quán)問題被清晰地劃分開。在本文中，我會向您介紹這兩種安全篩選器，并將身份驗證和授權(quán)作為 ASP.NET Web API 中獨立的兩個方面，向您演示如何使用它們來實現(xiàn)將身份驗證和授權(quán)。

實現(xiàn)安全性方面的選項

通過使用由主機提供的擴展點以及由 ASP.NET Web API 管道自己提供的擴展點能夠?qū)崿F(xiàn) ASP.NET Web API 中的身份驗證和授權(quán)。基于主機的選項包括 HTTP 模塊和 OWIN 中間件組件，而 ASP.NET Web API 的擴展選項包括消息處理程序、操作篩選器、授權(quán)篩選器以及身份驗證篩選器。

基于主機的選項很好地集成到主機管道中，并能較早拒絕管道中的無效請求。另一方面，ASP.NET Web API 的擴展選項對身份驗證過程提供更精細的控制水平。也就是說，您可以對不同的控制器甚至不同的操作方法設(shè)置不同的身份驗證機制。權(quán)衡與主機更好地集成在一起，并較早對不佳的身份驗證粒度請求予以拒絕。除了這些常規(guī)特性，每個選項都有自己的優(yōu)缺點，我將在后面的章節(jié)中進行介紹。

HTTP 模塊這是在 IIS 上運行的一個 Web API 選項。作為 IIS 管道的一部分，HTTP 模塊允許較早地執(zhí)行安全代碼。從 HTTP 模塊中建立的主體適用于所有的組件，包括管道中稍后運行的 IIS 組件。例如，如果主體是由響應(yīng) AuthenticateRequest 事件的 HTTP 模塊構(gòu)建的，則主體的用戶名將被正確地記錄在 IIS 日志的 cs-username 字段中。HTTP 模塊的最大缺點是缺乏粒度。HTTP 模塊對進入應(yīng)用程序的所有請求做出運行反應(yīng)。對于具有不同功能（如 HTML 標記生成，Web API 等等）的 Web 應(yīng)用程序，讓一個 HTTP 模塊以某種方式強制執(zhí)行身份驗證通常不是一個很靈活的方法。在這種情況下，另一個使用 HTTP 模塊的缺點就顯現(xiàn)出來了，即依賴主機—IIS。

OWIN 中間件這是另一個與主機相關(guān)的選項，適用于 OWIN 主機。ASP.NET Web API 2 完全支持 OWIN。使用 OWIN 中間件確保安全的可能最有說服力的理由是同一中間件可以在不同的框架中工作。這意味著您可以將多個框架（如 ASP.NET Web API、SignalR 等）用在您的應(yīng)用程序中，卻可以使用共同的安全中間件。然而，OWIN 中間件的最小粒度卻可能是一個缺點，因為 OWIN 中間件在 OWIN 管道中運行并且通常在處理各個請求時被調(diào)用。此外，OWIN 中間件只能用于與 OWIN 兼容的主機，雖然這種依賴比起依賴特定的主機/服務(wù)器（如 IIS）相對要好些，但這是 HTTP 模塊的實際情況。值得注意的一點是，正是由于 Microsoft.Owin.Host.SystemWeb 包，OWIN 中間件才可以在（集成了 IIS 的）ASP.NET 管道中運行。

消息處理程序由 ASP.NET Web API 提供的擴展選項，將使用消息處理程序確保安全的最大好處就是它作為 ASP.NET Web API 框架的概念可以不依賴底層的主機或服務(wù)器。此外，消息處理程序僅對 Web API 請求運行。使用消息處理程序的不足之處在于缺乏更精細的控制。可將消息處理程序配置為對所有請求或?qū)μ囟酚梢匀痔幚沓绦騺磉\行。對于給定的路由，您可以有多個控制器。所有這些控制器和它們所包含的操作方法都必須共享相同的由為此路由配置的消息處理程序強制執(zhí)行的身份驗證。換句話說，由消息處理程序執(zhí)行的身份驗證的最低粒度是在路由級別。

操作篩選器由 ASP.NET Web API 提供的另一個擴展選項是操作篩選器。然而，從執(zhí)行身份驗證的角度來看，它不是一個可行的選擇，僅僅是因為它在授權(quán)篩選器在 ASP.NET Web API 管道運行之后才開始運行。為了讓身份驗證和授權(quán)能正常工作，身份驗證必須先于授權(quán)而運行。

授權(quán)篩選器然而，由 ASP.NET Web API 提供的另一個擴展選項是授權(quán)篩選器。對于要求比消息處理程序能提供的更高的粒度的情形，執(zhí)行自定義身份驗證最常見的一種方式是使用授權(quán)篩選器。將授權(quán)篩選器用于身份驗證和授權(quán)的主要問題是，ASP.NET Web API 并不保證身份驗證篩選器的執(zhí)行順序。基本上，這意味著在執(zhí)行身份驗證的授權(quán)篩選器運行之前，執(zhí)行授權(quán)的授權(quán)篩選器就可以正常運行了，從而使得授權(quán)篩選器選項如同操作篩選器選項一樣不適合身份驗證。

身份驗證篩選器這是本文的重點所在，它是可用于 ASP.NET Web API 2 的最新擴展選項。身份驗證篩選器在消息處理程序之后運行，并且是在其他所有篩選器類型之前運行。因此，它們是實現(xiàn)身份驗證相關(guān)操作的更好選擇。最重要的是，身份驗證篩選器是在授權(quán)篩選器之前運行的。通過使用專門針對身份驗證或授權(quán)的篩選器，可以分別處理身份驗證和授權(quán)相關(guān)的問題。

此外，身份驗證篩選器提供控制或粒度級別，因此特別有用。以旨在被本機移動應(yīng)用程序和基于瀏覽器的 AJAX 應(yīng)用程序所使用的 Web API 為例。移動應(yīng)用程序可能會在 HTTP Authorization 標頭中顯示一個令牌，而 AJAX 應(yīng)用程序可能將身份驗證 Cookie 用作憑據(jù)。此外，假設(shè) API 的子集是敏感的，且僅適用于本機移動應(yīng)用程序，您要確保只能通過提供令牌，而不是提供 Cookie 的方式來訪問操作方法（Cookie 很容易受到跨站點請求偽造 [XSRF] 的影響，而在 HTTP Authorization 標頭中的令牌則不會）。在這種情況下，身份驗證必須以比基于主機的選項，甚至是消息處理程序更精細的粒度級別進行。身份驗證篩選器非常適合這個用例。您可以應(yīng)用基于所有這些控制器的令牌上的身份驗證篩選器或必須使用的操作方法，以及基于其他地方的 Cookie 的身份驗證篩選器。假設(shè)，在這種情況下，您有一些常見的操作方法，想通過令牌或 Cookie 的方式來訪問它們。您可以將 Cookie 和令牌身份驗證篩選器均應(yīng)用在這些常見的操作方法上，總會有一個篩選器能夠成功進行身份驗證。這種控制是能被推上臺面的具有最大價值的身份驗證篩選器。當需要精確控制身份驗證時，正確的做法是，通過身份驗證篩選器解決身份驗證相關(guān)問題以及通過授權(quán)篩選器解決授權(quán)相關(guān)問題。

值得一提的是，開箱即用的身份驗證篩選器 (HostAuthenticationFilter) 通過 OWIN 中間件啟用了 ASP.NET Web API 身份驗證。當 OWIN 身份驗證中間件在管道中運行，并試圖“主動”身份驗證傳入的請求時，如需要，也可以將它配置為“被動”身份驗證傳入的請求。HostAuthenticationFilter 允許依據(jù) Web API 管道中后來的名稱運行被動 OWIN 身份驗證中間件。這種方法啟用了能夠在多框架間共享的身份驗證代碼（包括 Microsoft 提供的 OWIN 身份驗證中間件），同時仍允許將每個操作粒度用于身份驗證。

雖然您可以混合使用主機級別的身份驗證和基于更細粒度 Web API 管道的身份驗證，但是也必須仔細考慮主機級別的身份驗證會怎樣影響 Web API 身份驗證。例如，您可以使基于 Cookie 的身份驗證中間件處于主機級別，這意味著可以同其他框架配合使用，比如 ASP.NET MVC，但是讓 Web API 使用基于 Cookie 的主體會使得它容易受到（比如 XSRF 的）攻擊。為了幫助處理這種情況，SuppressDefaultHostAuthentication 擴展方法使 Web API 忽略在主機級別配置的任何身份驗證。默認的 Web API Visual Studio 模板在主機級別下啟用了 Cookie，并使用在 Web API 級別的承載令牌。因為 Cookie 是在主機級別下啟用的，并要求 XSRF 緩解，所以模板還使用 SuppressDefaultHostAuthentication 阻止 Web API 管線使用基于 Cookie 的主體。這樣一來，Web API 將只使用基于令牌的主體，您則不需要為 Web API 建立抵御 XSRF 攻擊的機制。

使身份驗證篩選器和授權(quán)篩選器協(xié)同工作

在 ASP.NET Web API 管道中，身份驗證篩選器第一個運行（緊接著運行的是授權(quán)篩選器）的原因很簡單，因為授權(quán)取決于確定的身份，而這正是身份驗證的結(jié)果。以下為您介紹如何設(shè)計身份驗證篩選器和授權(quán)篩選器以協(xié)同工作來保護 ASP.NET Web API。

設(shè)計的基本原則是讓身份驗證篩選器只負責驗證憑據(jù)，而不是讓其處理其他問題。例如，如果未提供憑據(jù)，身份驗證篩選器將不會拒絕有 401 未經(jīng)授權(quán)狀態(tài)代碼的請求。它根本沒有確定一個經(jīng)過身份驗證的身份，并將如何處理匿名請求的問題留給了授權(quán)階段。身份驗證篩選器基本執(zhí)行三種類型的操作：

如果感興趣的憑據(jù)不存在于該請求中，則篩選器就不執(zhí)行任何操作。

如果存在憑據(jù)且該憑據(jù)是有效的，則篩選器會以經(jīng)過身份驗證的主體的形式確定一個身份。

如果存在憑據(jù)但該憑據(jù)是無效的，篩選器就會通過設(shè)置一個錯誤的結(jié)果通知 ASP.NET Web API 框架，這基本上可導(dǎo)致向請求者發(fā)回一個“未經(jīng)授權(quán)”的響應(yīng)。

如果管道中運行的身份驗證篩選器都無法檢測到無效的憑據(jù)，則該管道將繼續(xù)運行，即使還沒有驗證未確定的身份。只有根據(jù)后來在管道中運行的組件，才能確定如何處理這個匿名請求。

在最基本的層面上，授權(quán)篩選器只檢查所確定的身份是否是經(jīng)過身份驗證的身份。然而，授權(quán)篩選器也可以確保：

• 經(jīng)過身份驗證的身份的用戶名在經(jīng)過允許的用戶列表上。
• 至少有一個與經(jīng)過身份驗證的身份相關(guān)的角色會列在經(jīng)過允許的角色列表上。

雖然開箱即用的授權(quán)篩選器只根據(jù)剛才的描述執(zhí)行基于角色的訪問控制，但是來自開箱即用授權(quán)篩選器的自定義授權(quán)篩選器卻可以通過檢查屬于由身份驗證篩選器確定的身份的聲明來執(zhí)行基于聲明的訪問控制。

如果所有的授權(quán)篩選器都運行正常，管道將繼續(xù)執(zhí)行，最終 API 控制器的操作方法會生成一個針對請求的響應(yīng)。如果未確定身份，或者如果在用戶名或角色要求方面存在不匹配，則授權(quán)篩選器將拒絕存在 401 未授權(quán)響應(yīng)的請求。圖 1 說明了兩種篩選器在三種情況下所扮演的角色：不存在憑據(jù)、提供的憑據(jù)無效和存在的憑據(jù)有效。

圖 1 ASP.NET Web API 管道中的安全篩選器

創(chuàng)建身份驗證篩選器

身份驗證篩選器是一個實現(xiàn) IAuthenticationFilter 接口的類。這個接口提供兩種方法：AuthenticateAsync 和 ChallengeAsync，如下所示：

public interface IAuthenticationFilter : IFilter {Task AuthenticateAsync(HttpAuthenticationContext context,?CancellationToken cancellationToken);Task ChallengeAsync(HttpAuthenticationChallengeContext context,CancellationToken cancellationToken); }

AuthenticateAsync 方法接受 HttpAuthenticationContext 作為參數(shù)。此上下文就是 AuthenticateAsync 方法將身份驗證的結(jié)果反饋給 ASP.NET Web API 框架的方式。如果請求消息中包含真實的憑據(jù)，傳入 HttpAuthenticationContext 對象的 Principal 屬性將被設(shè)置為經(jīng)過身份驗證的主體。如果憑據(jù)無效，HttpAuthenticationContext 參數(shù)的 ErrorResult 屬性將設(shè)置為 UnauthorizedResult。如果該請求消息根本不包含憑據(jù)，則 AuthenticateAsync 方法不執(zhí)行任何操作。圖 2 中的代碼顯示了涵蓋這三種情況的 AuthenticateAsync 方法的典型實現(xiàn)。在這個示例中使用的經(jīng)過身份驗證的主體是只有名稱和角色聲明的 ClaimsPrincipal。

圖 2 AuthenticateAsync 方法

public Task AuthenticateAsync(HttpAuthenticationContext context,CancellationToken cancellationToken) {var req = context.Request;// Get credential from the Authorization header //(if present) and authenticateif (req.Headers.Authorization != null &&"somescheme".Equals(req.Headers.Authorization.Scheme,StringComparison.OrdinalIgnoreCase)){var creds = req.Headers.Authorization.Parameter;if(creds == "opensesame") // Replace with a real check{var claims = new List<Claim>(){new Claim(ClaimTypes.Name, "badri"),new Claim(ClaimTypes.Role, "admin")};var id = new ClaimsIdentity(claims, "Token");var principal = new ClaimsPrincipal(new[] { id });// The request message contains valid credentialcontext.Principal = principal;}else{// The request message contains invalid credentialcontext.ErrorResult = new UnauthorizedResult(new AuthenticationHeaderValue[0], context.Request);}}return Task.FromResult(0); }

您可以使用 AuthenticateAsync 方法來實現(xiàn)驗證請求中的憑據(jù)的核心身份驗證邏輯，并使用 ChallengeAsync 方法添加身份驗證質(zhì)詢。當狀態(tài)代碼是 401 未經(jīng)授權(quán)時，身份驗證質(zhì)詢被加入到響應(yīng)中，為了檢查狀態(tài)代碼，您需要該響應(yīng)對象。但 ChallengeAsync 方法不允許您檢查響應(yīng)或直接設(shè)置質(zhì)詢。事實上，這種方法是在操作方法之前在 Web API 管道的請求處理部分中執(zhí)行的。然而，ChallengeAsync 方法的參數(shù) HttpAuthenticationChallengeContext 允許將操作結(jié)果對象 (IHttpActionResult) 分配給 Result 屬性。操作結(jié)果對象的 ExecuteAsync 方法等待任務(wù)生成響應(yīng)，檢查響應(yīng)狀態(tài)代碼，并添加 WWW-Authenticate 響應(yīng)標頭。圖 3 中的代碼顯示了 ChallengeAsync 方法的典型實現(xiàn)。在這個示例中，我只添加一個經(jīng)過硬編碼的質(zhì)詢。ResultWithChallenge 類是我創(chuàng)建用來添加質(zhì)詢的操作結(jié)果類。

圖 3 ChallengeAsync 方法

public Task ChallengeAsync(HttpAuthenticationChallengeContext context,CancellationToken cancellationToken) {context.Result = new ResultWithChallenge(context.Result);return Task.FromResult(0); } public class ResultWithChallenge : IHttpActionResult {private readonly IHttpActionResult next;public ResultWithChallenge(IHttpActionResult next){this.next = next;}public async Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken){var response = await next.ExecuteAsync(cancellationToken);if (response.StatusCode == HttpStatusCode.Unauthorized){response.Headers.WwwAuthenticate.Add(new AuthenticationHeaderValue("somescheme", "somechallenge"));}return response;} }

下面的代碼顯示了完整的篩選器類：

public class TokenAuthenticationAttribute : Attribute, IAuthenticationFilter {public bool AllowMultiple { get { return false; } }// The AuthenticateAsync and ChallengeAsync methods go here }

除了實現(xiàn) IAuthenticationFilter 接口，從屬性中派生可以將此類用作類（控制器）級或方法（操作方法）級的屬性。

因此，您可以創(chuàng)建一個只負責身份驗證特定憑據(jù)（本例中的虛假令牌）的身份驗證篩選器。身份驗證篩選器沒有授權(quán)邏輯；它唯一目的是處理身份驗證：（在處理請求消息時如果有的話）確定身份，（在處理響應(yīng)消息時如果有的話）返回質(zhì)詢。授權(quán)篩選器處理授權(quán)問題，如檢查身份是否是經(jīng)過身份驗證的身份或者已在經(jīng)過允許的用戶或角色列表中列出。

使用授權(quán)篩選器

使用授權(quán)篩選器的基本目標是執(zhí)行授權(quán)，以確定用戶是否有權(quán)訪問所請求的資源。Web API 提供了所謂的 AuthorizeAttribute 授權(quán)篩選器的使用。應(yīng)用該篩選器可確保身份是經(jīng)過身份驗證的身份。您還可以使用允許的特定用戶名和角色列表配置授權(quán)屬性。圖 4 中的代碼顯示了使用不同的身份屬性來授權(quán)，在不同級別（總的來說，是控制器級別和操作方法級別）應(yīng)用的授權(quán)篩選器。本示例中的篩選器整體上保證了身份是經(jīng)過身份驗證了的。在控制器級別使用的篩選器保證了身份是經(jīng)過身份驗證了的，并且與該身份相關(guān)聯(lián)的角色中至少有一個是“管理員”。在操作方法級別使用的篩選器確保了身份是經(jīng)過身份驗證的，且用戶名是“badri”。這里要注意的一點是，在操作方法級別的授權(quán)篩選器也繼承了控制器級別和全局級別的篩選器。因此，若要成功完成授權(quán)，所有篩選器都必須通過：用戶名必須是“badri”，其中一個角色必須是“管理員”，且用戶必須經(jīng)過身份驗證。

圖 4 使用處于三個不同級別的授權(quán)篩選器

public static class WebApiConfig {public static void Register(HttpConfiguration config){// Other Web API configuration code goes hereconfig.Filters.Add(new AuthorizeAttribute()); // Global level} } [Authorize(Roles="admin")] // Controller level public class EmployeesController : ApiController {[Authorize(Users="badri")] // Action method levelpublic string Get(int id){return “Hello World”;} }

開箱即用的 AuthorizeAttribute 非常有用，但是如果需要更多的自定義，您可以對其劃分子類，來實現(xiàn)其他的授權(quán)行為。下面的代碼顯示了一個自定義的授權(quán)篩選器：

public class RequireAdminClaimAttribute : AuthorizeAttribute {protected override bool IsAuthorized(HttpActionContext context){var principal =context.Request.GetRequestContext().Principal as ClaimsPrincipal;return principal.Claims.Any(c => c.Type =="http://yourschema/identity/claims/admin"&& c.Value == "true");} }

這個篩選器只檢查“管理員”自定義聲明，但您可以使用 HttpActionContext 中的主體和其他附加信息在這里進行自定義授權(quán)。

在 ASP.NET Web API 的第一個版本中，自定義授權(quán)篩選器經(jīng)常被誤用來實現(xiàn)身份驗證，但對于 ASP.NET Web API 2，身份驗證篩選器現(xiàn)在管道中有自己的地方，這有助于開發(fā)干凈的模塊化代碼，便于分開考慮身份驗證和授權(quán)方面的問題。

篩選器覆蓋

正如我剛才解釋的，授權(quán)篩選器可以應(yīng)用在操作方法級別、控制器級別或全局級別。通過全局指定授權(quán)篩選器，您可以在所有控制器范圍內(nèi)強制執(zhí)行對所有操作方法調(diào)用的授權(quán)。如果您想通過一些方法免于執(zhí)行全局配置檢查，那么使用 AllowAnonymous 屬性可以輕松做到這一點。

圖 5 中的代碼顯示了在控制器級別對 AllowAnonymous 屬性的使用。雖然授權(quán)篩選器在全局范圍中應(yīng)用，但與 PublicResourcesController 一起使用的 AllowAnonymous 屬性可免于對傳入此控制器的請求執(zhí)行授權(quán)。

圖 5 使用 AllowAnonymous 屬性

public static class WebApiConfig {public static void Register(HttpConfiguration config){// Other Web API configuration code goes hereconfig.Filters.Add(new AuthorizeAttribute()); // Global level} } [AllowAnonymous] public class PublicResourcesController : ApiController {public string Get(int id){return “Hello World”;} }

AllowAnonymous 屬性提供了一種方式，讓特定的操作可以覆蓋由更高級別的授權(quán)篩選器配置的授權(quán)。然而，AllowAnonymous 只允許您覆蓋授權(quán)。假設(shè)您最想要使用 HTTP 基本身份驗證對大多數(shù)操作進行身份驗證，但有一個操作只能用令牌進行身份驗證。全局配置令牌身份驗證而隨后對此操作覆蓋身份驗證（類似于 AllowAnonymous 覆蓋授權(quán)的方式）會是不錯的方法。

ASP.NET Web API 2 引入了一種新的篩選器類型，以解決這種情況，即覆蓋篩選器。不同于 AllowAnonymous，ASP.NET Web API 2 中引入的覆蓋篩選器可與任何類型的篩選器一同工作。覆蓋篩選器，顧名思義，可以覆蓋在更高級別上配置的篩選器。若要覆蓋在更高層次上配置的身份驗證篩選器，請使用開箱即用的屬性 OverrideAuthentication。如果您有一個適合全局使用的身份驗證篩選器，并希望阻止它運行特定的操作方法或控制器，您可以僅在所需的級別上應(yīng)用 OverrideAuthentication。

覆蓋篩選器的作用遠不止于阻止某些篩選器運行。假設(shè)您有兩種身份驗證篩選器，一個用于驗證安全令牌，另一個用于在 HTTP 基本方案中驗證用戶名/密碼。這兩種篩選器都在全局范圍內(nèi)應(yīng)用，使您的 API 足夠靈活，可以接受令牌或用戶名/密碼。下面的代碼顯示了在全局范圍內(nèi)應(yīng)用的兩種身份驗證篩選器：

public static class WebApiConfig {public static void Register(HttpConfiguration config){// Other Web API configuration code goes hereconfig.Filters.Add(new TokenAuthenticator());config.Filters.Add(new HttpBasicAuthenticator(realm: "Magical"));} }

現(xiàn)在，也許您想確保只將令牌用作訪問特定操作方法的憑據(jù)。OverrideAuthentication 如何使您能夠滿足這種需求，難道是它禁止所有篩選器運行？下面是覆蓋篩選器的重要特征，他們清除了在更高級別上指定的所有篩選器，但不刪除與其在同一級別上指定的篩選器。這基本上意味著您可以在某個特定級別上添加一個或多個身份驗證篩選器，同時清除在更高級別上的所有其他篩選器。回到僅將令牌用作為訪問特定操作方法的憑據(jù)的要求，您可以簡單地在操作方法級別上指定 OverrideAuthentication 屬性和 TokenAuthenticator 屬性，如下面的代碼所示（這可以確保只有 TokenAuthenticator 為操作方法 GetAllowedForTokenOnly 運行）：

public class EmployeesController : ApiController {[OverrideAuthentication] // Removes all authentication filters[TokenAuthenticator] // Puts back only the token authenticatorpublic string GetAllowedForTokenOnly(int id){return “Hello World”;} }

因此，引入了 ASP.NET Web API 2 的覆蓋篩選器在全局范圍內(nèi)指定篩選器，并在較低級別上選擇性地在必須只對全局行為進行覆蓋的領(lǐng)域運行篩選器方面提供了更大的靈活性。

除了 OverrideAuthentication 屬性，另外還有開箱即用的稱為 OverrideAuthorization 的屬性，它可以刪除在更高級別上指定的授權(quán)篩選器。與 AllowAnonymous 相比，不同之處在于 OverrideAuthorization 只刪除更高級別上的授權(quán)篩選器。但不刪除與其在相同級別上的指定的授權(quán)篩選器。AllowAnonymous 使 ASP.NET Web API 可以跳過相關(guān)的授權(quán)過程，即使是與 AllowAnonymous 在相同級別上指定的授權(quán)篩選器，都將被忽略。

總結(jié)

您可以使用由主機提供的選項，以及由 ASP.NET Web API 管道提供的擴展點在 ASP.NET Web API 中執(zhí)行身份驗證。基于主機的選項很好地集成到主機管道中，并在早期拒絕管道中的無效請求。ASP.NET Web API 擴展點提供對身份驗證過程更精細的控制級別。如果您需要對身份驗證執(zhí)行更多的控制，例如，要對不同的控制器，甚至不同的操作方法使用不同的身份驗證機制，正確的做法是，通過身份驗證篩選器解決身份驗證相關(guān)問題以及通過授權(quán)篩選器解決授權(quán)相關(guān)問題。

轉(zhuǎn)載于:https://www.cnblogs.com/leleroyn/p/4318619.html

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Web API 安全筛选器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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