Secure ASP.NET Core server-side Blazor apps

This article explains how to secure server-side Blazor apps as ASP.NET Core applications.

Server-side Blazor apps are configured for security in the same manner as ASP.NET Core apps. For more information, see the articles under ASP.NET Core security topics.

The authentication context is only established when the app starts, which is when the app first connects to the WebSocket. The authentication context is maintained for the lifetime of the circuit. Apps periodically revalidate the user's authentication state every 30 minutes.

If the app must capture users for custom services or react to updates to the user, see Server-side ASP.NET Core Blazor additional security scenarios.

Blazor differs from a traditional server-rendered web apps that make new HTTP requests with cookies on every page navigation. Authentication is checked during navigation events. However, cookies aren't involved. Cookies are only sent when making an HTTP request to a server, which isn't what happens when the user navigates in a Blazor app. During navigation, the user's authentication state is checked within Blazor's SignalR circuit, which you can update at any time on the server using a revalidating AuthenticationStateProvider](#additional-authentication-state-providers).

Important

Implementing a custom NavigationManager to achieve authentication validation during navigation isn't recommended. If the app must execute custom authentication state logic during navigation, use a custom AuthenticationStateProvider.

Note

The code examples in this article adopt nullable reference types (NRTs) and .NET compiler null-state static analysis, which are supported in ASP.NET Core in .NET 6 or later. When targeting ASP.NET Core 5.0 or earlier, remove the null type designation (?) from the examples in this article.

Server-side security of sensitive data and credentials

In test/staging and production environments, server-side Blazor code and web APIs should use secure authentication flows that avoid maintaining credentials within project code or configuration files. Outside of local development testing, we recommend avoiding the use of environment variables to store sensitive data, as environment variables aren't the most secure approach. For local development testing, the Secret Manager tool is recommended for securing sensitive data. For more information, see the following resources:

• Secure authentication flows (ASP.NET Core documentation)
• Managed identities for Microsoft Azure services (Blazor documentation)

For client-side and server-side local development and testing, use the Secret Manager tool to secure sensitive credentials.

Project template

Create a new server-side Blazor app by following the guidance in Tooling for ASP.NET Core Blazor.

Visual Studio

After choosing the server-side app template and configuring the project, select the app's authentication under Authentication type:

• None (default): No authentication.
• Individual Accounts: User accounts are stored within the app using ASP.NET Core Identity.

Visual Studio Code

When issuing the .NET CLI command to create and configure the server-side Blazor app, indicate the authentication mechanism with the -au|--auth option:

-au {AUTHENTICATION}

Note

For the full command, see Tooling for ASP.NET Core Blazor.

Permissible authentication values for the {AUTHENTICATION} placeholder are shown in the following table.

Authentication mechanism	Description
None (default)	No authentication
Individual	Users stored in the app with ASP.NET Core Identity

For more information, see the dotnet new command in the .NET Core Guide.

.NET CLI

When issuing the .NET CLI command to create and configure the server-side Blazor app, indicate the authentication mechanism with the -au|--auth option:

-au {AUTHENTICATION}

Note

For the full command, see Tooling for ASP.NET Core Blazor.

Permissible authentication values for the {AUTHENTICATION} placeholder are shown in the following table.

Authentication mechanism	Description
None (default)	No authentication
Individual	Users stored in the app with ASP.NET Core Identity

For more information:

• See the dotnet new command in the .NET Core Guide.

• Execute the help command for the template in a command shell:

  dotnet new {PROJECT TEMPLATE} --help
  

  In the preceding command, the {PROJECT TEMPLATE} placeholder is the project template.

Blazor Identity UI (Individual Accounts)

Blazor supports generating a full Blazor-based Identity UI when you choose the authentication option for Individual Accounts.

The Blazor Web App template scaffolds Identity code for a SQL Server database. The command line version uses SQLite and includes a SQLite database for Identity.

The template:

• Supports interactive server-side rendering (interactive SSR) and client-side rendering (CSR) scenarios with authenticated users.
• Adds Identity Razor components and related logic for routine authentication tasks, such as signing users in and out. The Identity components also support advanced Identity features, such as account confirmation and password recovery and multifactor authentication using a third-party app. Note that the Identity components themselves don't support interactivity.
• Adds the Identity-related packages and dependencies.
• References the Identity packages in _Imports.razor.
• Creates a custom user Identity class (ApplicationUser).
• Creates and registers an EF Core database context (ApplicationDbContext).
• Configures routing for the built-in Identity endpoints.
• Includes Identity validation and business logic.

To inspect the Blazor framework's Identity components, access them in the Pages and Shared folders of the Account folder in the Blazor Web App project template (reference source).

When you choose the Interactive WebAssembly or Interactive Auto render modes, the server handles all authentication and authorization requests, and the Identity components render statically on the server in the Blazor Web App's main project.

The framework provides a custom AuthenticationStateProvider in both the server and client (.Client) projects to flow the user's authentication state to the browser. The server project calls AddAuthenticationStateSerialization, while the client project calls AddAuthenticationStateDeserialization. Authenticating on the server rather than the client allows the app to access authentication state during prerendering and before the .NET WebAssembly runtime is initialized. The custom AuthenticationStateProvider implementations use the Persistent Component State service (PersistentComponentState) to serialize the authentication state into HTML comments and then read it back from WebAssembly to create a new AuthenticationState instance. For more information, see the Manage authentication state in Blazor Web Apps section.

Only for Interactive Server solutions, IdentityRevalidatingAuthenticationStateProvider (reference source) is a server-side AuthenticationStateProvider that revalidates the security stamp for the connected user every 30 minutes an interactive circuit is connected.

Blazor Identity depends on DbContext instances not created by a factory, which is intentional because DbContext is sufficient for the project template's Identity components to render statically without supporting interactivity.

For a description on how global interactive render modes are applied to non-Identity components while at the same time enforcing static SSR for the Identity components, see ASP.NET Core Blazor render modes.

For more information on persisting prerendered state, see Prerender ASP.NET Core Razor components.

Note

Documentation links to .NET reference source usually load the repository's default branch, which represents the current development for the next release of .NET. To select a tag for a specific release, use the Switch branches or tags dropdown list. For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

Manage authentication state in Blazor Web Apps

This section applies to Blazor Web Apps that adopt:

• Individual Accounts
• Client-side rendering (CSR, WebAssembly-based interactivity).

A client-side authentication state provider is only used within Blazor and isn't integrated with the ASP.NET Core authentication system. During prerendering, Blazor respects the metadata defined on the page and uses the ASP.NET Core authentication system to determine if the user is authenticated. When a user navigates from one page to another, a client-side authentication provider is used. When the user refreshes the page (full-page reload), the client-side authentication state provider isn't involved in the authentication decision on the server. Since the user's state isn't persisted by the server, any authentication state maintained client-side is lost.

To address this, the best approach is to perform authentication within the ASP.NET Core authentication system. The client-side authentication state provider only takes care of reflecting the user's authentication state. Examples for how to accomplish this with authentication state providers are demonstrated by the Blazor Web App project template and described below.

In the server project's Program file, call AddAuthenticationStateSerialization, which serializes the AuthenticationState returned by the server-side AuthenticationStateProvider using the Persistent Component State service (PersistentComponentState):

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

The API only serializes the server-side name and role claims for access in the browser. To include all claims, set SerializeAllClaims to true in the server-side call to AddAuthenticationStateSerialization:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

In the client (.Client) project's Program file, call AddAuthenticationStateDeserialization, which adds an AuthenticationStateProvider where the AuthenticationState is deserialized from the server using AuthenticationStateData and the Persistent Component State service (PersistentComponentState). There should be a corresponding call to AddAuthenticationStateSerialization in the server project.

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

Additional claims and tokens from external providers

To store additional claims from external providers, see Persist additional claims and tokens from external providers in ASP.NET Core.

Azure App Service on Linux with Identity Server

Specify the issuer explicitly when deploying to Azure App Service on Linux with Identity Server. For more information, see Use Identity to secure a Web API backend for SPAs.

Inject AuthenticationStateProvider for services scoped to a component

Don't attempt to resolve AuthenticationStateProvider within a service that's scoped to a component by OwningComponentBase because it results in the creation of a new instance of the AuthenticationStateProvider that isn't correctly initialized.

To access the AuthenticationStateProvider within a service scoped to a component, inject the AuthenticationStateProvider directly into the component and pass the service instance to the scoped service as a parameter. This approach ensures that the correct, initialized instance of the AuthenticationStateProvider is used for each user app instance.

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

In the Program file, the ExampleService is registered as a scoped service. In this example, the service is scoped to a component with OwningComponentBase. For general guidance on the lifetime of scoped services, see Dependency injection in ASP.NET Core.

.AddScoped<ExampleService>();

In the following InjectAuthStateProvider component:

• The component inherits OwningComponentBase.
• The AuthenticationStateProvider is injected and passed to ExampleService.ExampleMethod.
• ExampleService is resolved with OwningComponentBase.ScopedServices and GetRequiredService, which returns the correct, initialized instance of ExampleService that exists for the lifetime of the user's circuit.

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

For more information, see the guidance on OwningComponentBase in ASP.NET Core Blazor dependency injection.

Unauthorized content display while prerendering with a custom AuthenticationStateProvider

To avoid showing unauthorized content, for example content in an AuthorizeView component, while prerendering with a custom AuthenticationStateProvider, adopt one of the following approaches:

• Implement IHostEnvironmentAuthenticationStateProvider for the custom AuthenticationStateProvider to support prerendering: For an example implementation of IHostEnvironmentAuthenticationStateProvider, see the Blazor framework's ServerAuthenticationStateProvider implementation in ServerAuthenticationStateProvider.cs (reference source).

  Note

  Documentation links to .NET reference source usually load the repository's default branch, which represents the current development for the next release of .NET. To select a tag for a specific release, use the Switch branches or tags dropdown list. For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

• Disable prerendering: Indicate the render mode with the prerender parameter set to false at the highest-level component in the app's component hierarchy that isn't a root component.

  Note

  Making a root component interactive, such as the App component, isn't supported. Therefore, prerendering can't be disabled directly by the App component.

  For apps based on the Blazor Web App project template, prerendering is typically disabled where the Routes component is used in the App component (Components/App.razor) :

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Also, disable prerendering for the HeadOutlet component:

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  You can also selectively control the render mode applied to the Routes component instance. For example, see ASP.NET Core Blazor render modes.

• Authenticate the user on the server before the app starts: To adopt this approach, the app must respond to a user's initial request with the Identity-based sign-in page or view and prevent any requests to Blazor endpoints until they're authenticated. For more information, see Create an ASP.NET Core app with user data protected by authorization. After authentication, unauthorized content in prerendered Razor components is only shown when the user is truly unauthorized to view the content.

User state management

In spite of the word "state" in the name, AuthenticationStateProvider isn't for storing general user state. AuthenticationStateProvider only indicates the user's authentication state to the app, whether they are signed into the app and who they are signed in as.

Authentication uses the same ASP.NET Core Identity authentication as Razor Pages and MVC apps. The user state stored for ASP.NET Core Identity flows to Blazor without adding additional code to the app. Follow the guidance in the ASP.NET Core Identity articles and tutorials for the Identity features to take effect in the Blazor parts of the app.

For guidance on general state management outside of ASP.NET Core Identity, see ASP.NET Core Blazor state management.

Additional authentication state providers

Two additional classes derived from AuthenticationStateProvider help with managing authentication state on the server:

• ServerAuthenticationStateProvider (reference source): A default AuthenticationStateProvider used by the Blazor framework to manage authentication state on the server when a more specific provider isn't registered.

• RevalidatingServerAuthenticationStateProvider (reference source): A base class for AuthenticationStateProvider services that receive an authentication state from the host environment and revalidate it at regular intervals. See the Blazor Web App project template for an example implementation. Override RevalidationInterval to change the default 30 minute revalidation interval.

Note

Documentation links to .NET reference source usually load the repository's default branch, which represents the current development for the next release of .NET. To select a tag for a specific release, use the Switch branches or tags dropdown list. For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

Authentication state management at sign out

Server-side Blazor persists user authentication state for the lifetime of the circuit, including across browser tabs. To proactively sign off a user across browser tabs when the user signs out on one tab, you must implement a RevalidatingServerAuthenticationStateProvider (reference source) with a short RevalidationInterval.

Note

Documentation links to .NET reference source usually load the repository's default branch, which represents the current development for the next release of .NET. To select a tag for a specific release, use the Switch branches or tags dropdown list. For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

Temporary redirection URL validity duration

This section applies to Blazor Web Apps.

Use the RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration option to get or set the lifetime of ASP.NET Core Data Protection validity for temporary redirection URLs emitted by Blazor server-side rendering. These are only used transiently, so the lifetime only needs to be long enough for a client to receive the URL and begin navigation to it. However, it should also be long enough to allow for clock skew across servers. The default value is five minutes.

In the following example the value is extended to seven minutes:

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

Additional resources

• Quickstart: Add sign-in with Microsoft to an ASP.NET Core web app
• Quickstart: Protect an ASP.NET Core web API with Microsoft identity platform
• Configure ASP.NET Core to work with proxy servers and load balancers: Includes guidance on:
  • Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks.
  • Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies.