Authentication and Authorization

Two words that get used interchangeably and must not be. Authentication is finding out who somebody is. Authorization is deciding what that person is allowed to do. A signed-in user is authenticated; whether they may see a salary is a separate question with a separate answer.

How the sign-in happens is outside this lesson: an identity provider, ASP.NET Core Identity, cookies issued by the host application. What all of them end up providing is the same thing — an AuthenticationStateProvider that can tell Blazor who the current user is, expressed as a ClaimsPrincipal.

The rest of the lesson is about what components do with that, and about one line you should read twice: hiding a button is presentation. It is not enforcement. Everything else here is mechanics; that distinction is the part that costs people money when they get it wrong.

// Program.cs — current .NET registers the cascade as a service
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ViewSalary", policy =>
        policy.RequireClaim("permission", "view-salary"));
});

@* Components/Routes.razor *@
<Router AppAssembly="typeof(Program).Assembly">
    <Found Context="routeData">
        <AuthorizeRouteView RouteData="routeData" DefaultLayout="typeof(MainLayout)">
            <Authorizing>
                <p role="status">Checking your access…</p>
            </Authorizing>
            <NotAuthorized>
                @if (context.User.Identity?.IsAuthenticated is true)
                {
                    <p role="alert">
                        You do not have access to this page. Contact the IT service
                        desk if you think you should.
                    </p>
                }
                else
                {
                    <RedirectToSignIn />
                }
            </NotAuthorized>
        </AuthorizeRouteView>
        <FocusOnNavigate RouteData="routeData" Selector="h1" />
    </Found>
</Router>

• AddCascadingAuthenticationState makes the current user available to every component as a cascading value, without any component having to inject anything. Older projects do the same job by wrapping the router in a <CascadingAuthenticationState> component; the registration is the current form and the effect is identical.
• AuthorizeRouteView replaces RouteView. It renders the page when the visitor is allowed to see it, and one of its own fragments when they are not.
• The two failure cases are genuinely different and the markup separates them. Not signed in means send them to sign in. Signed in but not permitted means say so plainly, because sending that person to a sign-in page produces a loop they cannot escape.
• The Authorizing fragment covers the gap while the answer is being worked out. Leave it out and the page can flash "you do not have access" before the check completes, and people believe the first thing they read.
• A policy is registered once and named. "ViewSalary" survives a reorganisation; a role name written into fifteen components does not.
• RedirectToSignIn is a small component you write — a few lines that navigate to your sign-in address with a return path. Nothing built in knows where your sign-in page is.
• FocusOnNavigate moves keyboard focus to the new page's heading. Without it, a keyboard or screen reader user stays where they were and has no idea the page changed.

@page "/employees/{Id:int}/salary"
@attribute [Authorize(Policy = "ViewSalary")]
@rendermode InteractiveServer

<h1>Salary</h1>

<AuthorizeView Policy="EditSalary">
    <Authorized Context="auth">
        <p>Signed in as @auth.User.Identity?.Name</p>
        <button type="button" @onclick="StartEdit">Edit salary</button>
    </Authorized>
    <NotAuthorized>
        <p>You can view this record. Changing it needs an HR administrator.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    [Parameter]
    public int Id { get; set; }

    private void StartEdit() { /* opens the edit form */ }
}

• @attribute [Authorize] applies the attribute to the generated component class. The router checks it before rendering, so an unauthorised visitor sees the NotAuthorized content from the previous section instead of this page.
• [Authorize] with no arguments means "signed in". Adding Policy or Roles narrows it from there.
• AuthorizeView renders one of its two fragments according to the answer. It does not guard the route — it is inside a page that is already guarded, deciding what to show within it.
• Two levels of permission on one screen: viewing is enforced by the route, editing changes what is rendered. That pairing is common and worth recognising, because it is where the next callout applies.
• Context="auth" names the fragment's context so the markup does not rely on the implicit name. Inside it, auth.User is a ClaimsPrincipal — the same type you would have on the server.
• The NotAuthorized branch explains rather than leaving a gap. A button that is absent with no reason reads as a broken page to whoever expected it.
• There is an Authorizing fragment here too, and it matters when the check involves an async call. Without it, the view shows the not-authorised branch first and then corrects itself, which is worse than showing nothing.

@inject AuthenticationStateProvider AuthProvider

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? AuthenticationStateTask { get; set; }

    private bool canApproveLeave;

    protected override async Task OnParametersSetAsync()
    {
        if (AuthenticationStateTask is null)
        {
            return;
        }

        var state = await AuthenticationStateTask;
        var user = state.User;

        canApproveLeave =
            user.Identity?.IsAuthenticated is true
            && user.HasClaim("permission", "approve-leave");
    }

    private async Task<string> DescribeCurrentUserAsync()
    {
        var state = await AuthProvider.GetAuthenticationStateAsync();
        return state.User.Identity?.Name ?? "not signed in";
    }
}

• The cascading value is a Task<AuthenticationState>, not a finished state object, because the answer may not have arrived yet. Awaiting it is how a component says "I need this before I decide".
• It is nullable because a component rendered outside the cascade never receives it. Treating a missing value as "not permitted" is the safe reading, which is what the early return does here.
• HasClaim asks a question without assuming the claim is present. Indexing into claims and reading .Value throws for anyone signed in through a provider that issues a different set.
• OnParametersSetAsync rather than OnInitializedAsync, because the cascading value can be supplied again and a component is reused when its parameters change.
• AuthenticationStateProvider is the service behind the cascade. Inject it when you need the user outside the render flow, or in a service a component calls. It also raises a notification when the user signs in or out, which is what lets AuthorizeView update without a page reload.
• Prefer the cascading Task inside components. Calling the provider on every render works and does more work than it needs to.