ASP.NET Core 驗證的概觀

作者:Mike Rousos

驗證是用來判斷使用者身分識別的程序。 授權是用來判斷使用者是否有權存取資源的程序。 在 ASP.NET Core 中,會由驗證中介軟體所使用的驗證服務 IAuthenticationService 來處理驗證。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 在未經驗證的使用者嘗試存取受限制的資源時做出回應。

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

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

例如,下列程式碼會為 cookie 和 JWT 持有人驗證配置註冊驗證服務和處理常式:

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

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

驗證概念

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

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

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

DefaultScheme

當只註冊單一驗證配置時,此單一驗證配置:

若要停用以單一驗證配置作為 DefaultScheme,請呼叫 AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme")

驗證配置

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

驗證配置是與下列項目對應的名稱:

  • 驗證處理常式。
  • 用於設定該處理常式特定執行個體的選項。

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

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

驗證處理常式

驗證處理常式有下列特性:

根據驗證配置的設定和傳入的要求內容,驗證處理常式:

  • 會在驗證成功時建構代表使用者身分識別的 AuthenticationTicket 物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 有方法可在使用者嘗試存取資源時採取挑戰和禁止動作:
    • 使用者未獲得存取授權 (禁止)。
    • 使用者未經驗證時 (挑戰)。

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 結果。

挑戰動作應該會讓使用者知道用來存取所要求資源的驗證機制。

禁止

當已驗證的使用者嘗試存取其不能存取的資源時,授權便會呼叫驗證配置的禁止動作。 請參閱 ForbidAsync。 驗證禁止範例包括:

  • cookie 驗證配置,會將使用者重新導向至指出禁止存取的頁面。
  • JWT 持有人配置,會傳回 403 結果。
  • 自訂驗證配置,會重新導向至使用者可以要求資源存取權的頁面。

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

  • 其已通過驗證。
  • 其不能存取所要求的資源。

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

每一租用戶的驗證提供者

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

Orchard Core 是:

  • 使用 ASP.NET Core 所建置的開放原始碼、模組化和多租用戶應用程式架構。
  • 以該應用程式架構為基礎的內容管理系統 (CMS)。

如需每一租用戶驗證提供者的範例,請參閱 Orchard Core 來源。

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

Finbuckle.MultiTenant:

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

其他資源

作者:Mike Rousos

驗證是用來判斷使用者身分識別的程序。 授權是用來判斷使用者是否有權存取資源的程序。 在 ASP.NET Core 中,會由驗證中介軟體所使用的驗證服務 IAuthenticationService 來處理驗證。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 在未經驗證的使用者嘗試存取受限制的資源時做出回應。

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

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

例如,下列程式碼會為 cookie 和 JWT 持有人驗證配置註冊驗證服務和處理常式:

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

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

驗證概念

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

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

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

驗證配置

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

驗證配置是與下列項目對應的名稱:

  • 驗證處理常式。
  • 用於設定該處理常式特定執行個體的選項。

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

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

驗證處理常式

驗證處理常式有下列特性:

根據驗證配置的設定和傳入的要求內容,驗證處理常式:

  • 會在驗證成功時建構代表使用者身分識別的 AuthenticationTicket 物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 有方法可在使用者嘗試存取資源時採取挑戰和禁止動作:
    • 使用者未獲得存取授權 (禁止)。
    • 使用者未經驗證時 (挑戰)。

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 結果。

挑戰動作應該會讓使用者知道用來存取所要求資源的驗證機制。

禁止

當已驗證的使用者嘗試存取其不能存取的資源時,授權便會呼叫驗證配置的禁止動作。 請參閱 ForbidAsync。 驗證禁止範例包括:

  • cookie 驗證配置,會將使用者重新導向至指出禁止存取的頁面。
  • JWT 持有人配置,會傳回 403 結果。
  • 自訂驗證配置,會重新導向至使用者可以要求資源存取權的頁面。

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

  • 其已通過驗證。
  • 其不能存取所要求的資源。

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

每一租用戶的驗證提供者

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

Orchard Core 是:

  • 使用 ASP.NET Core 所建置的開放原始碼、模組化和多租用戶應用程式架構。
  • 以該應用程式架構為基礎的內容管理系統 (CMS)。

如需每一租用戶驗證提供者的範例,請參閱 Orchard Core 來源。

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

其他資源

作者:Mike Rousos

驗證是用來判斷使用者身分識別的程序。 授權是用來判斷使用者是否有權存取資源的程序。 在 ASP.NET Core 中,會由驗證中介軟體所使用的驗證服務 IAuthenticationService 來處理驗證。 驗證服務會使用已註冊的驗證處理常式來完成驗證相關動作。 驗證相關動作的範例包括:

  • 驗證使用者。
  • 在未經驗證的使用者嘗試存取受限制的資源時做出回應。

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

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

例如,下列程式碼會為 cookie 和 JWT 持有人驗證配置註冊驗證服務和處理常式:

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

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

  • UseRouting 之後,以便能有路由資訊供系統決定驗證方式。
  • UseEndpoints 之前,以便使用者會先進行驗證再存取端點。

驗證概念

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

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

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

驗證配置

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

驗證配置是與下列項目對應的名稱:

  • 驗證處理常式。
  • 用於設定該處理常式特定執行個體的選項。

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

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

驗證處理常式

驗證處理常式有下列特性:

根據驗證配置的設定和傳入的要求內容,驗證處理常式:

  • 會在驗證成功時建構代表使用者身分識別的 AuthenticationTicket 物件。
  • 會在驗證失敗時傳回「沒有結果」或「失敗」。
  • 有方法可在使用者嘗試存取資源時採取挑戰和禁止動作:
    • 使用者未獲得存取授權 (禁止)。
    • 使用者未經驗證時 (挑戰)。

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 結果。

挑戰動作應該會讓使用者知道用來存取所要求資源的驗證機制。

禁止

當已驗證的使用者嘗試存取其不能存取的資源時,授權便會呼叫驗證配置的禁止動作。 請參閱 ForbidAsync。 驗證禁止範例包括:

  • cookie 驗證配置,會將使用者重新導向至指出禁止存取的頁面。
  • JWT 持有人配置,會傳回 403 結果。
  • 自訂驗證配置,會重新導向至使用者可以要求資源存取權的頁面。

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

  • 其已通過驗證。
  • 其不能存取所要求的資源。

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

每一租用戶的驗證提供者

ASP.NET Core 架構沒有適用於多租用戶驗證的內建解決方案。 雖然客戶可以撰寫使用多租用戶驗證的應用程式,但建議使用下列其中一個 ASP.NET Core 應用程式架構來支援多租用戶驗證:

Orchard Core

Orchard Core。 如需每一租用戶驗證提供者的範例,請參閱 Orchard Core 來源。

ABP Framework

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

其他資源