ASP.NET Core 認證概述

作者:Mike Rousos

驗證是確定使用者身分的程序。 授權是判斷使用者是否已access某資源的過程。 在 ASP.NET Core 中,認證由認證服務 處理,該服務由認證中介軟體使用。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 當未認證的使用者嘗試access受限資源時,會做出回應。

已註冊的驗證處理常式及其設定選項稱為「配置」。

驗證配置的指定方式是在 Program.cs 中註冊驗證服務:

例如,以下程式碼用來登記認證服務與處理程序,以及cookieJWT承載認證方案:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

如果未要求特定配置,則預設會使用的配置名稱是 AddAuthentication 參數 JwtBearerDefaults.AuthenticationScheme

如果使用多個方案,授權原則(或授權屬性)可以指定其用來驗證使用者的一或多個驗證方案。 在上述範例中,若要使用 cookie 驗證配置,則可以指定其名稱 (預設值是 CookieAuthenticationDefaults.AuthenticationScheme,不過在呼叫 AddCookie 時可提供不同的名稱)。

在某些情況下,其他擴充方法會自動呼叫 AddAuthentication。 例如,當使用 ASP.NET Core Identity 時,內部會呼叫 AddAuthentication

呼叫 Program.cs 即可在 UseAuthentication 中新增驗證中介軟體。 呼叫 UseAuthentication 會註冊中介軟體,而且此中介軟體使用的是先前已註冊的驗證配置。 在任何相依於使用者驗證的中介軟體之前,請呼叫 UseAuthentication

驗證概念

驗證會負責為授權提供 ClaimsPrincipal,以作為決定權限的依據。 有多個驗證配置方法可選取哪一個驗證處理常式負責產生正確的宣告集:

當只註冊單一驗證配置時,它就會變成預設配置。 如果已註冊多個配置且未指定預設配置,則必須在授權屬性中指定配置,否則會擲回下列錯誤:

InvalidOperationException:未指定身份驗證方案(authenticationScheme),而且找不到預設驗證方案(DefaultAuthenticateScheme)。 您可以使用 AddAuthentication(string defaultScheme) 或 AddAuthentication(Action<AuthenticationOptions> configureOptions) 來設定預設配置。

DefaultScheme

當只註冊單一驗證機制時,該單一驗證機制:

若要停用自動使用單一驗證方案作為 DefaultScheme,請呼叫 AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme")

驗證配置

驗證配置可選取哪一個驗證處理常式負責產生正確的宣告集。 如需詳細資訊,請參閱使用特定配置來授權

驗證方案是對應於以下項目的名稱:

  • 驗證處理程序。
  • 用於配置特定處理常式實例的選項。

方案可用作參考機制,以參考相關處理程序的驗證、挑戰和禁止行為。 例如,授權原則可以使用配置名稱來指定應該用來驗證使用者的一或多個驗證配置。 在設定驗證時,通常會指定預設驗證配置。 除非資源有要求特定配置,否則系統會使用預設配置。 您也可以:

  • 指定要用於驗證、挑戰和禁止動作的不同預設配置。
  • 使用策略方案可將多個方案合併成一個。

驗證處理常式

一個驗證處理程序:

根據驗證配置和傳入要求的上下文,驗證處理程序:

  • 若認證成功,則建構 AuthenticationTicket 代表使用者身份的物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 當使用者嘗試access資源時,設置挑戰與禁止行動的方法:
    • 他們未經授權訪問(被禁止)。
    • 使用者未經驗證時 (挑戰)。

RemoteAuthenticationHandler<TOptions>AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> 是需要遠端驗證步驟的驗證所屬的類別。 當遠端驗證步驟完成時,處理常式會回頭呼叫處理常式所設定的 CallbackPath。 處理器會使用傳遞至 HandleRemoteAuthenticateAsync 回呼路徑的資訊來完成驗證步驟。 OAuth 2.0OIDC 都使用此模式。 JWT 而 Cookie 則不需要,因為它們可以直接使用承載標頭來 cookie 認證。 在此案例中,遠端託管的提供者:

  • 是驗證提供者。
  • 範例包括 FacebookTwitterGoogleMicrosoft,以及任何其他使用處理常式機制來處理驗證使用者程序的 OIDC 提供者。

驗證

認證方案的認證動作負責根據請求上下文建構使用者身份。 它回傳 , AuthenticateResult 顯示驗證是否成功,若成功,則會在驗證單中顯示使用者身份。 參見 AuthenticateAsync。 驗證範例包括:

  • 一種 cookie 由 Cookie 建構使用者身份的認證方案。
  • 承載方案透過 JWT 反序列化並驗證 JWT 承載憑證,以建構使用者身份。

挑戰

當未經驗證的使用者要求存取需要驗證的端點時,授權便會叫用驗證挑戰。 例如,當匿名使用者要求受限制的資源或遵循登入連結時,系統就會發出驗證挑戰。 授權會使用指定的認證方案啟動挑戰,若未指定則為預設。 參見 ChallengeAsync。 驗證挑戰範例包括:

  • cookie 驗證配置,會將使用者重新導向至登入頁面。
  • 一種 JWT 帶有 www-authenticate: bearer 頭銜的 401 分結果的持牌方案。

挑戰動作應告知使用者該使用何種認證機制來access所請求的資源。

禁止

當經過認證的使用者嘗試存取他們不被允許存取的資源時,授權系統會觸發一個禁止操作。 參見 ForbidAsync。 身份驗證禁止範例包括:

  • 將使用者導向顯示禁止存取頁面的cookie 認證方案。
  • 一個 JWT 持有人方案,結果為403。
  • 一種自訂的認證機制,會導向到一個頁面,使用者可以在那裡請求存取資源的權限。

禁止動作可讓使用者知道:

  • 他們已通過驗證。
  • 他們不被允許access請求的資源。

若要知道挑戰與禁止有何差異,請參閱下列連結:

每一租用戶的驗證提供者

ASP.NET Core 沒有內建多租戶認證的解決方案。 雖然客戶也可以利用內建功能撰寫,但我們建議考慮使用 Orchard CoreABP FrameworkFinbuckle.MultiTenant 進行多租戶認證。

Orchard Core 是:

  • 一個以 ASP.NET Core 建構的開源、模組化且多租戶的應用程式框架。
  • 以該應用程式架構為基礎的內容管理系統 (CMS)。

請參閱 Orchard Core 來源,以了解每個租戶的認證提供者範例。

ABP Framework 支援各種架構模式,包括模組化、微服務、領域驅動設計,以及多租用戶。 請參閱ABP 框架的原始碼,GitHub

Finbuckle.MultiTenant:

  • 開放原始碼
  • 提供租戶解析
  • 輕量型
  • 提供資料隔離
  • 為每個租用戶專門設定應用程式行為

其他資源

作者:Mike Rousos

驗證是確定使用者身分的程序。 授權是判斷使用者是否已access某資源的過程。 在 ASP.NET Core 中,認證由認證服務 處理,該服務由認證中介軟體使用。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 當未認證的使用者嘗試access受限資源時,會做出回應。

已註冊的驗證處理常式及其設定選項稱為「配置」。

驗證配置的指定方式是在 Program.cs 中註冊驗證服務:

例如,以下程式碼用來登記認證服務與處理程序,以及cookieJWT承載認證方案:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

如果未要求特定配置,則預設會使用的配置名稱是 AddAuthentication 參數 JwtBearerDefaults.AuthenticationScheme

如果使用多個方案,授權原則(或授權屬性)可以指定其用來驗證使用者的一或多個驗證方案。 在上述範例中,若要使用 cookie 驗證配置,則可以指定其名稱 (預設值是 CookieAuthenticationDefaults.AuthenticationScheme,不過在呼叫 AddCookie 時可提供不同的名稱)。

在某些情況下,其他擴充方法會自動呼叫 AddAuthentication。 例如,當使用 ASP.NET Core Identity 時,內部會呼叫 AddAuthentication

呼叫 Program.cs 即可在 UseAuthentication 中新增驗證中介軟體。 呼叫 UseAuthentication 會註冊中介軟體,而且此中介軟體使用的是先前已註冊的驗證配置。 在任何相依於使用者驗證的中介軟體之前,請呼叫 UseAuthentication

驗證概念

驗證會負責為授權提供 ClaimsPrincipal,以作為決定權限的依據。 有多個驗證配置方法可選取哪一個驗證處理常式負責產生正確的宣告集:

系統不會自動探查協議。 如果未指定預設配置,就必須在授權屬性中指定配置,否則系統會擲回下列錯誤:

InvalidOperationException:未指定身份驗證方案(authenticationScheme),而且找不到預設驗證方案(DefaultAuthenticateScheme)。 您可以使用 AddAuthentication(string defaultScheme) 或 AddAuthentication(Action<AuthenticationOptions> configureOptions) 來設定預設配置。

驗證配置

驗證配置可選取哪一個驗證處理常式負責產生正確的宣告集。 如需詳細資訊,請參閱使用特定配置來授權

驗證方案是對應於以下項目的名稱:

  • 驗證處理程序。
  • 用於配置特定處理常式實例的選項。

方案可用作參考機制,以參考相關處理程序的驗證、挑戰和禁止行為。 例如,授權原則可以使用配置名稱來指定應該用來驗證使用者的一或多個驗證配置。 在設定驗證時,通常會指定預設驗證配置。 除非資源有要求特定配置,否則系統會使用預設配置。 您也可以:

  • 指定要用於驗證、挑戰和禁止動作的不同預設配置。
  • 使用策略方案可將多個方案合併成一個。

驗證處理常式

一個驗證處理程序:

根據驗證配置和傳入要求的上下文,驗證處理程序:

  • 若認證成功,則建構 AuthenticationTicket 代表使用者身份的物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 當使用者嘗試access資源時,設置挑戰與禁止行動的方法:
    • 他們未經授權訪問(被禁止)。
    • 使用者未經驗證時 (挑戰)。

RemoteAuthenticationHandler<TOptions>AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> 是需要遠端驗證步驟的驗證所屬的類別。 當遠端驗證步驟完成時,處理常式會回頭呼叫處理常式所設定的 CallbackPath。 處理器會使用傳遞至 HandleRemoteAuthenticateAsync 回呼路徑的資訊來完成驗證步驟。 OAuth 2.0OIDC 都使用此模式。 JWT 而 Cookie 則不需要,因為它們可以直接使用承載標頭來 cookie 認證。 在此案例中,遠端託管的提供者:

  • 是驗證提供者。
  • 範例包括 FacebookTwitterGoogleMicrosoft,以及任何其他使用處理常式機制來處理驗證使用者程序的 OIDC 提供者。

驗證

認證方案的認證動作負責根據請求上下文建構使用者身份。 它回傳 , AuthenticateResult 顯示驗證是否成功,若成功,則會在驗證單中顯示使用者身份。 參見 AuthenticateAsync。 驗證範例包括:

  • 一種 cookie 由 Cookie 建構使用者身份的認證方案。
  • 承載方案透過 JWT 反序列化並驗證 JWT 承載憑證,以建構使用者身份。

挑戰

當未經驗證的使用者要求存取需要驗證的端點時,授權便會叫用驗證挑戰。 例如,當匿名使用者要求受限制的資源或遵循登入連結時,系統就會發出驗證挑戰。 授權會使用指定的認證方案啟動挑戰,若未指定則為預設。 參見 ChallengeAsync。 驗證挑戰範例包括:

  • cookie 驗證配置,會將使用者重新導向至登入頁面。
  • 一種 JWT 帶有 www-authenticate: bearer 頭銜的 401 分結果的持牌方案。

挑戰動作應告知使用者該使用何種認證機制來access所請求的資源。

禁止

當經過認證的使用者嘗試存取他們不被允許存取的資源時,授權系統會觸發一個禁止操作。 參見 ForbidAsync。 身份驗證禁止範例包括:

  • 將使用者導向顯示禁止存取頁面的cookie 認證方案。
  • 一個 JWT 持有人方案,結果為403。
  • 一種自訂的認證機制,會導向到一個頁面,使用者可以在那裡請求存取資源的權限。

禁止動作可讓使用者知道:

  • 他們已通過驗證。
  • 他們不被允許access請求的資源。

若要知道挑戰與禁止有何差異,請參閱下列連結:

每一租用戶的驗證提供者

ASP.NET Core 沒有內建多租戶認證的解決方案。 雖然客戶也可以利用內建功能撰寫驗證,但我們建議考慮使用 Orchard CoreABP Framework來進行多租戶驗證。

Orchard Core 是:

  • 一個以 ASP.NET Core 建構的開源、模組化且多租戶的應用程式框架。
  • 以該應用程式架構為基礎的內容管理系統 (CMS)。

請參閱 Orchard Core 來源,以了解每個租戶的認證提供者範例。

ABP Framework 支援各種架構模式,包括模組化、微服務、領域驅動設計,以及多租用戶。 請參閱ABP 框架的原始碼,GitHub

其他資源

作者:Mike Rousos

驗證是確定使用者身分的程序。 授權是判斷使用者是否已access某資源的過程。 在 ASP.NET Core 中,認證由認證服務 處理,該服務由認證中介軟體使用。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 當未認證的使用者嘗試access受限資源時,會做出回應。

已註冊的驗證處理常式及其設定選項稱為「配置」。

驗證配置的指定方式是在 Startup.ConfigureServices 中註冊驗證服務:

例如,以下程式碼用來登記認證服務與處理程序,以及cookieJWT承載認證方案:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => Configuration.Bind("CookieSettings", options));

如果未要求特定配置,則預設會使用的配置名稱是 AddAuthentication 參數 JwtBearerDefaults.AuthenticationScheme

如果使用多個方案,授權原則(或授權屬性)可以指定其用來驗證使用者的一或多個驗證方案。 在上述範例中,若要使用 cookie 驗證配置,則可以指定其名稱 (預設值是 CookieAuthenticationDefaults.AuthenticationScheme,不過在呼叫 AddCookie 時可提供不同的名稱)。

在某些情況下,其他擴充方法會自動呼叫 AddAuthentication。 例如,當使用 ASP.NET Core Identity 時,內部會呼叫 AddAuthentication

呼叫 Startup.Configure 即可在 UseAuthentication 中新增驗證中介軟體。 呼叫 UseAuthentication 會註冊中介軟體,而且此中介軟體使用的是先前已註冊的驗證配置。 在任何相依於使用者驗證的中介軟體之前,請呼叫 UseAuthentication。 使用端點路由時,UseAuthentication 的呼叫必須位於:

  • UseRouting 之後,路由資訊將可用於系統進行驗證決策。
  • UseEndpoints 之前,使用者必須先完成驗證,然後才能存取端點。

驗證概念

驗證會負責為授權提供 ClaimsPrincipal,以作為決定權限的依據。 有多個驗證配置方法可選取哪一個驗證處理常式負責產生正確的宣告集:

系統不會自動探查協議。 如果未指定預設配置,就必須在授權屬性中指定配置,否則系統會擲回下列錯誤:

InvalidOperationException:未指定身份驗證方案(authenticationScheme),而且找不到預設驗證方案(DefaultAuthenticateScheme)。 您可以使用 AddAuthentication(string defaultScheme) 或 AddAuthentication(Action<AuthenticationOptions> configureOptions) 來設定預設配置。

驗證配置

驗證配置可選取哪一個驗證處理常式負責產生正確的宣告集。 如需詳細資訊,請參閱使用特定配置來授權

驗證方案是對應於以下項目的名稱:

  • 驗證處理程序。
  • 用於配置特定處理常式實例的選項。

方案可用作參考機制,以參考相關處理程序的驗證、挑戰和禁止行為。 例如,授權原則可以使用配置名稱來指定應該用來驗證使用者的一或多個驗證配置。 在設定驗證時,通常會指定預設驗證配置。 除非資源有要求特定配置,否則系統會使用預設配置。 您也可以:

  • 指定要用於驗證、挑戰和禁止動作的不同預設配置。
  • 使用策略方案可將多個方案合併成一個。

驗證處理常式

一個驗證處理程序:

根據驗證配置和傳入要求的上下文,驗證處理程序:

  • 若認證成功,則建構 AuthenticationTicket 代表使用者身份的物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 當使用者嘗試access資源時,設置挑戰與禁止行動的方法:
    • 他們未經授權訪問(被禁止)。
    • 使用者未經驗證時 (挑戰)。

RemoteAuthenticationHandler<TOptions>AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> 是需要遠端驗證步驟的驗證所屬的類別。 當遠端驗證步驟完成時,處理常式會回頭呼叫處理常式所設定的 CallbackPath。 處理器會使用傳遞至 HandleRemoteAuthenticateAsync 回呼路徑的資訊來完成驗證步驟。 OAuth 2.0OIDC 都使用此模式。 JWT 而 Cookie 則不需要,因為它們可以直接使用承載標頭來 cookie 認證。 在此案例中,遠端託管的提供者:

  • 是驗證提供者。
  • 範例包括 FacebookTwitterGoogleMicrosoft,以及任何其他使用處理常式機制來處理驗證使用者程序的 OIDC 提供者。

驗證

認證方案的認證動作負責根據請求上下文建構使用者身份。 它回傳 , AuthenticateResult 顯示驗證是否成功,若成功,則會在驗證單中顯示使用者身份。 參見 AuthenticateAsync。 驗證範例包括:

  • 一種 cookie 由 Cookie 建構使用者身份的認證方案。
  • 承載方案透過 JWT 反序列化並驗證 JWT 承載憑證,以建構使用者身份。

挑戰

當未經驗證的使用者要求存取需要驗證的端點時,授權便會叫用驗證挑戰。 例如,當匿名使用者要求受限制的資源或遵循登入連結時,系統就會發出驗證挑戰。 授權會使用指定的認證方案啟動挑戰,若未指定則為預設。 參見 ChallengeAsync。 驗證挑戰範例包括:

  • cookie 驗證配置,會將使用者重新導向至登入頁面。
  • 一種 JWT 帶有 www-authenticate: bearer 頭銜的 401 分結果的持牌方案。

挑戰動作應告知使用者該使用何種認證機制來access所請求的資源。

禁止

當經過認證的使用者嘗試存取他們不被允許存取的資源時,授權系統會觸發一個禁止操作。 參見 ForbidAsync。 身份驗證禁止範例包括:

  • 將使用者導向顯示禁止存取頁面的cookie 認證方案。
  • 一個 JWT 持有人方案,結果為403。
  • 一種自訂的認證機制,會導向到一個頁面,使用者可以在那裡請求存取資源的權限。

禁止動作可讓使用者知道:

  • 他們已通過驗證。
  • 他們不被允許access請求的資源。

若要知道挑戰與禁止有何差異,請參閱下列連結:

每一租用戶的驗證提供者

ASP.NET Core 框架沒有內建多租戶認證的解決方案。 雖然客戶也可以撰寫多租戶認證的應用程式,但我們建議使用以下支援多租戶認證的 ASP.NET Core 應用程式框架之一。

Orchard Core 是一個開源、模組化且多租戶的應用程式框架,採用 ASP.NET Core 建構,同時也提供內容管理系統(CMS)。 請參閱 Orchard Core 來源,以了解每個租戶的認證提供者範例。

ABP Framework 支援多種架構模式,包括模組化、微服務、領域驅動設計及多租戶。 請參閱ABP 框架的原始碼,GitHub

其他資源