Sign-in across render modes – Blazor in depth (W8, lesson 3)

What you learn in this lesson

explain where the sign-in state comes from in static SSR, in a server island and in a WebAssembly island

transfer the sign-in state to WebAssembly with AddAuthenticationStateSerialization and AddAuthenticationStateDeserialization and say what travels with it

enforce permissions on pages, parts of a page and endpoints, and justify why data in the browser is readable and permissions belong in the API

keep access tokens on the server and pass them on to an API with a token handler, without them reaching the browser

enforce signing out and expiry in the middle of a connection with a RevalidatingServerAuthenticationStateProvider

check the Kladde's internal area with roles in server and WebAssembly islands using a permissions matrix

In a classic web app, the cookie comes with every request, and the check happens every time. In a Blazor Web App with islands, that is true only for some of the pages: a server island checks the sign-in once, when the connection is set up, and a WebAssembly island runs in a browser whose code anyone can read and change. This lesson clarifies who is signed in in which mode, how the knowledge about it gets to WebAssembly, and which check applies where.

Where the Kladde stands

The lesson assumes K2 2.6: cookie sign-in and [Authorize] (K2 2.6.1), Entra ID with Microsoft.Identity.Web (2.6.2), roles and policies (2.6.3) and the permissions matrix (2.6.4). The Kladde has sign-in as the endpoints /sign-in and /sign-out, a fallback policy and, under /internal, the pages with islands from W8.1.1: the calendar (server) and the contact list (WebAssembly). In K2 2.6.3, the app roles are called office and management; this course writes them as Staff and Admin, keep your own role names. The Entra sign-in from K2 2.6.2 stays as it is; the examples here use the development sign-in from 2.6.1, because it can be tested.

What you learn in this lesson

Where the Kladde stands

This lesson belongs to course W8