共用方式為

保護 ASP.NET Core Blazor WebAssembly

  • 發行項

注意

這不是這篇文章的最新版本。 如需目前的版本，請參閱 本文的 .NET 9 版本。

警告

不再支援此版本的 ASP.NET Core。 如需詳細資訊，請參閱 .NET 和 .NET Core 支持原則。 如需目前的版本，請參閱 本文的 .NET 9 版本。

重要

這些發行前產品的相關資訊在產品正式發行前可能會有大幅修改。 Microsoft 對此處提供的資訊，不做任何明確或隱含的瑕疵擔保。

如需目前的版本，請參閱 本文的 .NET 9 版本。

Blazor WebAssembly 應用程式的保護方式與單頁應用程式 (SPA) 相同。 有數種方法可以向 SPA 驗證使用者，但最常見且完整的方法是使用以 OAuth 2.0 通訊協定為基礎的實作，例如 OpenID Connect (OIDC)。

Blazor WebAssembly 安全性文件主要著重於如何完成使用者驗證和授權工作。 如需 OAuth 2.0/OIDC 一般概念涵蓋範圍，請參閱主要概觀文章的其他資源一節中的資源。

敏感數據和認證的用戶端/SPA 安全性

Blazor WebAssembly 應用程式的 .NET/C# 程式碼基底是為給用戶端提供的，且應用程式的程式碼無法受到保護而免於使用者檢查和竄改。 永遠不要將認證或秘密放入Blazor WebAssembly應用程式，例如應用程式秘密、連接字串、密碼、私人 .NET/C# 程式代碼或其他敏感數據。

若要保護 .NET/C# 程式碼，並使用 ASP.NET Core 資料保護功能來保護資料，請使用伺服器端 ASP.NET Core Web API。 讓用戶端 Blazor WebAssembly 應用程式呼叫伺服器端 Web API，以保護應用程式功能和資料處理。 如需詳細資訊，請參閱從 ASP.NET Core Blazor 應用程式呼叫 Web API 和此節點中的文章。

針對本機開發測試， 建議使用秘密管理員工具 來保護敏感數據。

驗證程式庫

Blazor WebAssembly支援使用 Microsoft identity 平臺透過Microsoft.AspNetCore.Components.WebAssembly.Authentication連結庫使用 OIDC 驗證和授權應用程式。 此程式庫會提供一組基本類型，讓您順暢地針對 ASP.NET Core 後端進行驗證。 此程式庫可以針對支援 OIDC 的任何第三方 Identity 提供者 (IP) (稱為 OpenID 提供者 (OP)) 進行驗證。

Blazor WebAssembly 程式庫 (Authentication.js) 中的驗證支援是建置在 Microsoft 驗證程式庫 (MSAL，msal.js) 之上，其是用來處理基礎驗證通訊協定詳細資料。 Blazor WebAssembly 程式庫僅支援程式碼交換證明金鑰 (PKCE) 授權碼流程。 不支援隱含授與。

SPA 也有其他驗證選項，例如使用 SameSite Cookie。 不過，Blazor WebAssembly 的工程設計會使用 OAuth 和 OIDC 作為 Blazor WebAssembly 應用程式中的最佳驗證選項。 會選擇以 JSON Web 權杖 (JWT) 為基礎的權杖型驗證，而未選擇 cookie 型的驗證，主要是基於功能性與安全性考量：

  • 使用權杖型通訊協定發現漏洞會比較少，原因是所有要求不一定會傳送權杖。
  • 伺服器端點不需要防範跨網站偽造要求 (CSRF)，因為系統會明確地將權杖傳送至伺服器。 這可讓您與 MVC 或 Razor 頁面應用程式一起裝載 Blazor WebAssembly 應用程式。
  • 權杖的使用權限範圍比 Cookie 小。 例如，權杖無法用來管理使用者帳戶或變更使用者的密碼，除非您已明確實作這類功能。
  • 權杖的存留期較短 (一小時)，因此可限制攻擊時間範圍。 權杖也可以隨時撤銷。
  • 獨立式 JWT 可為用戶端和伺服器的驗證程序提供保證。 例如，用戶端有方法可以偵測並驗證其收到的權杖是否合法，以及是不是在指定的驗證程序中發出。 如果第三方試圖在驗證程序進行期間變換權杖，用戶端會偵測出遭到變換的權杖，並避免使用。
  • 使用 OAuth 和 OIDC 的權杖無須依靠使用者代理程式正確運作，即可確保應用程式安全無虞。
  • 權杖型通訊協定 (例如 OAuth 和 OIDC) 可讓您使用一組相同的安全性特性，來驗證和授權獨立 Blazor WebAssembly 應用程式中的使用者。
  • 使用權杖型通訊協定發現漏洞會比較少，原因是所有要求不一定會傳送權杖。
  • 伺服器端點不需要防範跨網站偽造要求 (CSRF)，因為系統會明確地將權杖傳送至伺服器。 這可讓您與 MVC 或 Razor 頁面應用程式一起裝載 Blazor WebAssembly 應用程式。
  • 權杖的使用權限範圍比 Cookie 小。 例如，權杖無法用來管理使用者帳戶或變更使用者的密碼，除非您已明確實作這類功能。
  • 權杖的存留期較短 (一小時)，因此可限制攻擊時間範圍。 權杖也可以隨時撤銷。
  • 獨立式 JWT 可為用戶端和伺服器的驗證程序提供保證。 例如，用戶端有方法可以偵測並驗證其收到的權杖是否合法，以及是不是在指定的驗證程序中發出。 如果第三方試圖在驗證程序進行期間變換權杖，用戶端會偵測出遭到變換的權杖，並避免使用。
  • 使用 OAuth 和 OIDC 的權杖無須依靠使用者代理程式正確運作，即可確保應用程式安全無虞。
  • 權杖型通訊協定 (例如 OAuth 和 OIDC) 可讓您使用一組相同的安全性特性，來驗證和授權所裝載 Blazor WebAssembly 解決方案用戶端和獨立 Blazor WebAssembly 應用程式的使用者。

重要

對於在 Blazor 專案範本中採用 Duende Identity Server 的 ASP.NET Core 版本，Duende Software 可能需要您支付授權費用，才能在實際執行中使用 Duende Identity Server。 如需詳細資訊，請參閱從 ASP.NET Core 5.0 移轉至 6.0。

使用 OIDC 的驗證程序

Microsoft.AspNetCore.Components.WebAssembly.Authentication 程式庫提供數個基本類型供您實作使用 OIDC 的驗證和授權程序。 廣泛地說，驗證的運作方式如下：

  • 當匿名使用者選取登入按鈕或要求套用了 [Authorize] 屬性的 Razor 元件或頁面時，系統會將使用者重新導向至應用程式的登入頁面 (/authentication/login)。
  • 在登入頁面中，驗證程式庫會準備重新導向至授權端點。 授權端點位於 Blazor WebAssembly 應用程式外部，而且可以裝載在不同的來源。 端點負責判斷使用者是否已通過驗證，並負責發出一或多個權杖以作為回應。 驗證程式庫會提供登入回呼來接收驗證回應。
    • 如果使用者未通過驗證，則系統會將使用者重新導向至基礎驗證系統，此系統通常是 ASP.NET Core Identity。
    • 如果使用者已通過驗證，授權端點便會產生適當權杖，並將瀏覽器重新導向回登入回呼端點 (/authentication/login-callback)。
  • 當 Blazor WebAssembly 應用程式載入登入回呼端點 (/authentication/login-callback) 時，系統便會處理驗證回應。
    • 如果驗證程序順利完成，使用者便會通過驗證，且系統會選擇性地讓其返回所要求的原始受保護 URL。
    • 如果驗證流程由於任何原因而失敗，系統會將使用者傳送至登入失敗頁面 (/authentication/login-failed)，其中會顯示錯誤。

Authentication 元件

Authentication 元件 (Authentication.razor) 會處理遠端驗證作業，並允許應用程式：

  • 設定驗證狀態的應用程式路由。
  • 設定驗證狀態的 UI 內容。
  • 管理驗證狀態。

驗證動作 (例如註冊或登入使用者) 會傳遞至 Blazor 架構的 RemoteAuthenticatorViewCore<TAuthenticationState> 元件，以保存及控制驗證作業之間的狀態。

如需詳細資訊和範例，請參閱 ASP.NET Core Blazor WebAssembly 的其他安全性案例。

授權

在 Blazor WebAssembly 應用程式中，授權檢查是可以被略過的，因為使用者可以修改所有的用戶端程式碼。 這同樣也適用於所有的用戶端應用程式技術，包括 JavaScript SPA 架構或任何作業系統的原生應用程式。

請一律在由您用戶端應用程式所存取之任何 API 端點內的伺服器上執行授權檢查。

自訂驗證

Blazor WebAssembly 提供方法來新增並擷取基礎驗證庫的其他參數，以便透過外部 identity 提供者來執行遠端驗證作業。

為了傳遞其他參數，NavigationManager 支援在執行外部位置變更時傳遞和擷取歷程記錄項目狀態。 如需詳細資訊，請參閱以下資源：

歷程記錄 API 所儲存的狀態，能夠為遠端驗證提供以下優點：

  • 傳遞至受保護應用程式端點的狀態，會繫結至為了在 authentication/login 端點驗證使用者而執行的導覽。
  • 避免額外的工作編碼和解碼資料。
  • 能減少漏洞。 不同於使用查詢字串來儲存導覽狀態，最上層導覽或來自不同來源的影響無法設定歷程記錄 API 所儲存的狀態。
  • 成功驗證時會取代歷程記錄專案，因此會移除附加至歷程記錄專案的狀態，而且不需要清除。

InteractiveRequestOptions 代表 identity 提供者登入，或者佈建存取權杖要求。

NavigationManagerExtensions 提供 NavigateToLogin 方法以用於登入作業，且提供 NavigateToLogout 方法以用於登出作業。 方法會呼叫 NavigationManager.NavigateTo，使用傳遞的 InteractiveRequestOptions 或由方法建立的新 InteractiveRequestOptions 執行個體來設定歷程記錄項目狀態，以用於：

ASP.NET Core Blazor WebAssembly 其他安全性範例文章中涵蓋了以下驗證案例：

  • 自訂登入程序
  • 使用自訂傳回 URL 登出
  • 使用互動方式，在取得權杖之前自訂選項
  • 在使用 IAccessTokenProvider 時自訂選項
  • 從驗證選項取得登入路徑

要求整個應用程式的授權

請使用下列其中「一種」方法，將 [Authorize] 屬性 (API 文件) 套用至應用程式的每個 Razor 元件：

  • 在應用程式的 Imports 檔案中，使用 [Authorize] 屬性的 @attribute 指示詞，為 Microsoft.AspNetCore.Authorization 命名空間新增 @using 指示詞。

    _Imports.razor：

    @using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

    允許匿名存取 Authentication 元件，才能允許重新導向至 identity 提供者。 將下列 Razor 程式碼新增至其 @page 指示詞下的 Authentication 元件。

    Authentication.razor：

    @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@attribute [AllowAnonymous]

  • 請將屬性新增至 @page 指示詞底下的每個 Razor 元件：

    @using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

注意

不支援將 AuthorizationOptions.FallbackPolicy 設定為具有 RequireAuthenticatedUser 的原則。

每款應用程式都會使用到一款 identity 提供者應用程式來完成註冊

此概觀下的一些文章與涉及兩個以上應用程式的 Blazor 裝載案例有關。 獨立 Blazor WebAssembly 應用程式會使用 Web API 搭配已驗證的使用者，來存取伺服器應用程式所提供的伺服器資源和資料。

在文件範例中執行此案例時，會使用到兩種identity 提供者註冊方式，一種可用於用戶端應用程式，另一種則適用用伺服器應用程式。 使用個別註冊，例如在 Microsoft Entra ID 中，並非絕對必要。 不過，使用兩個註冊是安全性最佳做法，因為其會依應用程式隔離註冊。 使用個別註冊也允許用戶端和伺服器註冊的獨立設定。

此概觀下的一些文章與下列任一涉及兩個以上應用程式的 Blazor 裝載案例有關：

  • 裝載的 Blazor WebAssembly 解決方案，由兩個應用程式組成：一個用戶端 Blazor WebAssembly 應用程式和一個伺服器端 ASP.NET Core 主機應用程式。 用戶端應用程式的已驗證使用者可存取伺服器應用程式所提供的伺服器資源和資料。
  • 一個獨立 Blazor WebAssembly 應用程式，其會使用 Web API 搭配已驗證的使用者，來存取伺服器應用程式所提供的伺服器資源和資料。 此案例類似於使用裝載的 Blazor WebAssembly 解決方案;但在此情況下，用戶端應用程式不是由伺服器應用程式裝載。

在文件範例中執行這些案例時，會使用到兩種identity 提供者註冊方式，一種可用於用戶端應用程式，另一種則適用於伺服器應用程式。 使用個別註冊，例如在 Microsoft Entra ID 中，並非絕對必要。 不過，使用兩個註冊是安全性最佳做法，因為其會依應用程式隔離註冊。 使用個別註冊也允許用戶端和伺服器註冊的獨立設定。

重新整理權杖

雖然無法在 Blazor WebAssembly 應用程式中保護重新整理權杖，但是如果您使用適當的安全性策略來實作這些權杖時，就可以使用這些權杖。

針對 .NET 6 或更新版本的 ASP.NET Core 中的獨立 Blazor WebAssembly 應用程式，建議使用：

針對裝載的 Blazor WebAssembly 解決方案，伺服器端應用程式可以維護和使用重新整理權杖，以便存取第三方 API。 如需詳細資訊，請參閱 ASP.NET Core Blazor WebAssembly 的其他安全性案例。

如需詳細資訊，請參閱以下資源：

建立使用者的宣告

應用程式通常會根據 Web API 對伺服器的呼叫來要求使用者的宣告。 例如，宣告經常會用來在應用程式中建立授權。 在這些案例中，應用程式會要求存取權杖來存取服務，並使用權杖來取得用於建立宣告的使用者資料。

例如，請參閱下列資源：

預先呈現支援

驗證端點 (/authentication/ 路徑區段) 不支援預先轉譯。

驗證端點 (/authentication/ 路徑區段) 不支援預先轉譯。

如需詳細資訊，請參閱 ASP.NET Core Blazor WebAssembly 的其他安全性案例。

Linux 上的 Azure App Service 與 Identity 伺服器

請在部署 Linux 上的 Azure App Service 與 Identity 伺服器時明確指定簽發者。

如需詳細資訊，請參閱使用 Identity 來保護 SPA 的 Web API 後端。

Windows 驗證

Windows 驗證不建議與 Blazor Webassembly 或任何其他 SPA 架構搭配使用。 建議您使用權杖型通訊協定而非 Windows 驗證，例如 OIDC 搭配 Active Directory Federation Services (ADFS)。

如果 Windows 驗證與 Blazor Webassembly 或任何其他 SPA 架構搭配使用，則需要採取額外措施來讓應用程式防範跨網站偽造要求 (CSRF) 權杖。 Cookie 會有的顧慮，Windows 驗證一樣會有，而且 Windows 驗證也沒有提供機制來防止跨來源共用驗證內容。 使用 Windows 驗證但沒有額外 CSRF 保護的應用程式，至少應限制為只能在組織的內部網路使用，而不能在開放網際網路上使用。

如需詳細資訊，請參閱防止 ASP.NET Core 中的跨網站要求偽造 (XSRF/CSRF) 攻擊。

保護 SignalR 中樞

若要在伺服器 API 專案中保護 SignalR 中樞，請將 [Authorize] 屬性套用至中樞類別或套用至中樞類別的方法。

在含有預先轉譯的用戶端專案中，例如託管的 Blazor WebAssembly (.NET 7 或是更早版本的 ASP.NET Core) 或 Blazor Web App (.NET 8 或是更新版本的 ASP.NET Core)，這部分還請參閱 ASP.NET Core BlazorSignalR 指導中的指導說明。

在沒有預先轉譯的用戶端專案元件中，例如獨立 Blazor WebAssembly 或非瀏覽器應用程式，提供中樞連線的存取權杖，如下列範例所示。 如需詳細資訊，請參閱 ASP.NET Core SignalR 中的驗證和授權。

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

記錄

本節適用於 Blazor WebAssembly.NET 7 或更新版本的 ASP.NET Core 中的應用程式。

若要啟用偵錯或追蹤記錄，請參閱 7.0 或更新版本的 ASP.NET CoreBlazor 記錄一文中的驗證記錄 (Blazor WebAssembly) 一節。

WebAssembly 沙箱

WebAssembly「沙箱」會限制對執行 WebAssembly 程式碼的系統環境進行存取，包括存取 I/O 子系統、系統儲存體和資源，以及作業系統。 WebAssembly 程式碼與執行程式碼的系統之間的隔離，使得 WebAssembly 成為系統的安全編碼架構。 不過，WebAssembly 容易受到硬體層級的旁路攻擊。 在採購硬體和限制存取硬體方面套用正常的預防措施和盡職調查。

WebAssembly 不是由 Microsoft 所擁有或維護。

如需詳細資訊，請參閱下列 W3C 資源：

實作指南

本「概觀」底下的文章可讓您了解如何針對特定提供者來驗證 Blazor WebAssembly 應用程式中的使用者。

獨立 Blazor WebAssembly 應用程式：

如需進一步的設定指引，請參閱下列文章：

搭配 PKCE 使用授權碼流程

Microsoft identity 平台的 適用於 JavaScript 的 Microsoft 驗證程式庫 (MSAL) v2.0 或更新版本有提供授權碼流程的支援 ，其中包含程式碼交換證明金鑰 (PKCE) 和 跨來源資源共用 (CORS)，適用於單頁應用程式，包括 Blazor 在內。

Microsoft 不建議使用隱含授與。

如需詳細資訊，請參閱以下資源：

其他資源