ASP.NET Core, Blazor und der verschwundene „Authenticated User“
Wir arbeiten aktuell an einer Eigenentwicklung auf Basis von C# ASP.NET Core und Blazor.
Im Zuge dieser Entwicklung haben wir natürlich auch die vom Framework bereitgestellte Login‑Mechanik implementiert. Und wie es bei .NET‑Updates manchmal ist: Nach einem Update funktionierte plötzlich nichts mehr so, wie es sollte.
Der Login selbst lief scheinbar korrekt durch. Im Konsolenlog erschien „User logged in“, aber in den nachfolgenden Bereichen — dort, wo Daten basierend auf dem aktuellen Benutzer geladen werden sollten — meldete das System plötzlich, dass kein „authenticated user“ vorhanden sei.
Merkwürdig.
Parallel dazu sorgten verschiedene Rücksetzungen von NuGet‑Paketen dafür, dass das Projekt in der Visual Studio 2022 Preview gar nicht mehr starten wollte. Die Lösung dafür war simpel: Projekt in der regulären Visual Studio 2022 Version öffnen. Die Preview war ursprünglich installiert worden, als MAUI, Blazor und .NET 8 gerade frisch integriert wurden — inzwischen aber nicht mehr notwendig.
Der eigentliche Fehler blieb jedoch bestehen:
Seite aufrufen → Weiterleitung zum Login → erfolgreicher Login → zurück zur ursprünglichen Seite → Benutzer nicht authentifiziert → keine Daten.
Die Anwendung ist eine hybride Blazor‑App, bestehend aus einem serverseitigen und einem clientseitigen Teil. Beide müssen — damit die Authentifizierung sauber funktioniert — den passenden AuthenticationStateProvider implementieren. Das war auch der Fall.
Allerdings hatte sich im Update‑Chaos unbemerkt ein Scope verändert:
builder.Services.AddScoped<AuthenticationStateProvider, PersistingRevalidatingAuthenticationStateProvider>();war plötzlich zu
builder.Services.AddScoped<AuthenticationStateProvider, IdentityRevalidatingAuthenticationStateProvider>();geworden.
Offenbar vertragen sich beide Varianten nicht besonders gut — zumindest nicht so, dass beide Seiten einer hybriden Blazor‑App zuverlässig mitbekommen, dass ein Benutzer erfolgreich eingeloggt wurde.
Nach der Rückumstellung funktionierte die Authentifizierung sofort wieder.
Woher die Änderung ursprünglich kam, können wir nicht sagen — und haben an der Stelle auch nicht weiter nachgeforscht. Wahrscheinlich hätte auch die umgekehrte Variante (beidseitige Umstellung auf IdentityRevalidatingAuthenticationStateProvider) funktioniert.
Wichtig war: Der Scope musste auf beiden Seiten konsistent sein.
Danach lief alles wieder stabil.