<!-- In App.razor -->
@inject PersistentComponentState ApplicationState
@inject IHostEnvironmentAuthenticationStateProvider HostAuthenticationStateProvider

<CascadingAuthenticationState>
    <Router AppAssembly="@typeof(Program).Assembly">
        ...
    </Router>
</CascadingAuthenticationState>

@code {
    private Task<AuthenticationState>? authenticationState;
    private IDisposable? subscription;

    protected override void OnInitialized()
    {
        authenticationState = HostAuthenticationStateProvider.GetAuthenticationStateAsync();
        subscription = ApplicationState.RegisterOnPersisting(PersistAuthenticationState);
    }

    private void PersistAuthenticationState()
    {
        // This gets the user claims and serializes them for the client
        if (authenticationState?.Result.User.Identity?.IsAuthenticated is true)
        {
            var userId = authenticationState.Result.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
            var email = authenticationState.Result.User.FindFirst(ClaimTypes.Email)?.Value;

            // Persist the necessary claims. Don't serialize the whole identity!
            ApplicationState.PersistAsJson("UserInfo", new UserInfo { UserId = userId, Email = email });
        }
    }

    public void Dispose() => subscription?.Dispose();
}

// In Client/Program.cs
builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddSingleton<AuthenticationStateProvider, PersistentAuthenticationStateProvider>();

Sometimes the sign-in process fails silently. You click "Log In," the page reloads, and you're right back at the login form. No error messages, just... nothing. This often points to an issue with how the authentication cookie or antiforgery tokens are being handled.

The Problem: Misconfigured Security Policies

Modern browsers have strict security policies around cookies (e.g., `SameSite` attributes). If your app's cookie policy is too restrictive, the browser might simply refuse to set or send the auth cookie on subsequent requests. Similarly, Blazor's antiforgery system is designed to prevent Cross-Site Request Forgery (CSRF) attacks and will block requests that don't have a valid token.

The Solution: Audit Your Startup Configuration

1. Check Your Cookie Configuration

In your server project's Program.cs, review your cookie authentication options. A common misstep is failing to configure the cookie name or security policy correctly, especially behind a proxy or in a complex hosting environment.

// In Server/Program.cs
builder.Services.AddAuthentication(IdentityConstants.ApplicationScheme)
    .AddIdentityCookies(options =>
    {
        // You can configure cookie options here if needed.
        // For example, if you're having issues with redirects:
        options.ApplicationCookie.Configure(opt =>
        {
            opt.LoginPath = "/Account/Login";
            opt.LogoutPath = "/Account/Logout";
        });
    });

Ensure your `LoginPath` points to the correct component. Also, be aware that in production, cookies should always be marked as `Secure` (only sent over HTTPS) and `HttpOnly` (inaccessible to client-side scripts).

2. Tame the Antiforgery Token

With interactive forms in Blazor, antiforgery protection is critical. If you have a standard `<form>` in a Razor component, you must include the antiforgery token.

First, ensure antiforgery services are registered in Program.cs:

// In Server/Program.cs
builder.Services.AddAntiforgery();

Then, in your component with a form, add the `<AntiforgeryToken />` component inside your `<EditForm>` or `<form>` tag. For endpoints that handle the form post, add the `[ValidateAntiForgeryToken]` attribute.

// In a login component like Login.razor
<EditForm Model="@Input" OnValidSubmit="LoginUser" FormName="login">
    <AntiforgeryToken />
    <DataAnnotationsValidator />
    ...
</EditForm>

If this token is missing or invalid, the server will reject the request, often resulting in an HTTP 400 Bad Request that can look like a failed login.

Fix 3: External Provider Redirect URI Nightmares

You’ve integrated Google, Azure AD, or another OIDC/OAuth provider. The user is correctly sent to the provider's login page, they enter their credentials, but upon returning to your app, they hit a 404 error or a provider-specific error page complaining about a `redirect_uri_mismatch`.

The Problem: A Simple Typo or Mismatch

This error is almost always what it says it is: the `redirect_uri` (or callback URL) your application sent to the provider does not exactly match one of the URIs you registered in that provider's developer portal.

This includes:

• HTTP vs. HTTPS
• The presence or absence of a trailing slash (`/`)
• The port number (e.g., `localhost:7123` vs. `localhost:5001`)
• Subdomains (`www.yourapp.com` vs. `yourapp.com`)

The Solution: Trace and Match with Precision

1. Find Your App's Actual Callback Path

The default callback path for generic OIDC providers in ASP.NET Core is `/signin-oidc`. For specific providers, it might be different (e.g., `/signin-google`). Your full redirect URI during local development will be something like `https://localhost:7123/signin-oidc`.

2. Use Browser DevTools to Be Sure

The easiest way to find the exact URI your app is sending is to use your browser's developer tools (F12).

1. Open the Network tab and check "Preserve log."
2. Click your "Login with Google" button.
3. Look for the first request that goes to the external provider (e.g., `accounts.google.com`).
4. Inspect the Query String Parameters for this request. You will see a `redirect_uri` parameter. This is the exact value you must register with the provider.

3. Update the Provider's Configuration

Go to your application's settings in the provider's portal (e.g., Azure AD App Registrations > Authentication) and add the URI you discovered to the list of allowed Redirect URIs. Add entries for both your local development environment and your production environment.

Conclusion

Blazor's authentication system is robust, but its integration across different rendering modes requires careful configuration. As we move further into 2025, mastering these concepts is key to a smooth development experience.

Next time you're stuck on a sign-in bug, remember these three core areas:

1. Authentication State: Is it being correctly persisted from server to client?
2. Cookies & Antiforgery: Are your security policies and tokens configured and included correctly?
3. Redirect URIs: Does your provider configuration exactly match the URI your application is sending?

By systematically checking these points, you can turn frustrating authentication puzzles into quick fixes and get back to building amazing applications with Blazor.