Fix #3895: BlazorAuthenticationChallengeHandler sends a local returnUrl instead of the absolute NavigationManager.Uri

[Devon (DevonEast)]

Fixes #3895.

Problem

BlazorAuthenticationChallengeHandler.ChallengeUser passes NavigationManager.Uri — always an absolute URL — as the returnUrl query parameter of the /authentication/login endpoint mapped by MapLoginAndLogout(). That endpoint validates returnUrl with RedirectUriHelper.IsLocalUrl, which (correctly) rejects absolute URLs and falls back to /. Net effect: every incremental-consent or Conditional Access round-trip in Blazor Server drops the user on the app root instead of returning them to the page they were on.

The two halves of the flow ship in the same assembly and are documented as a pair, but they disagree about the shape of returnUrl.

Why fix the sender, not the validator

The strict local-only validation in GetAuthProperties is a deliberate hardening: its regression tests pin that absolute URLs must be coerced to / (the earlier behaviour of coercing absolutes via PathAndQuery at the endpoint was removed as part of the open-redirect hardening). Relaxing the validator would reopen that surface. The sender, by contrast, can trivially produce the local form — it is the current page's URI.

This also mirrors what the MVC path already does: AccountController.Challenge accepts same-origin absolute URLs by coercing them to PathAndQuery (with an IsLocalUrl re-check on the coerced value), explicitly because the consent handler passes NavigationManager.Uri. This PR gives the Blazor Minimal-API path the equivalent treatment — at the sending end, so the endpoint's validation stays strict.

Change

ChallengeUser now sends new Uri(navigation.Uri).PathAndQuery:

• Preserves the app path base (https://host/app/page?x=1 → /app/page?x=1) — which is why it uses PathAndQuery rather than NavigationManager.ToBaseRelativePath.
• Drops the fragment, matching the MVC coercion's documented behaviour.
• Defensive re-check: PathAndQuery of a same-origin URL can still begin with // or /\ (e.g. a request path of //evil.example/x), which a downstream Location header would treat as protocol-relative. The coerced value is re-validated with RedirectUriHelper.IsLocalUrl and falls back to / — the same re-check AccountController.Challenge performs.

No public API change; no change to LoginLogoutEndpointRouteBuilderExtensions.

Tests

BlazorAuthenticationChallengeHandlerTests gains a concrete TestNavigationManager (a subclass calling Initialize() and overriding NavigateToCore — the pattern the ASP.NET Core repo uses), which makes NavigationManager.Uri/NavigateTo unit-testable. With it:

• New: ChallengeUser_SendsLocalReturnUrl_PreservingPathAndQuery — returnUrl is the escaped local /admin/reports?tab=2, forceLoad: true.
• New: ChallengeUser_LocalReturnUrl_PreservesPathBase — an app under /app/ keeps its base.
• New: ChallengeUser_ProtocolRelativePathShape_CoercedToRoot — a //evil.example/x path shape coerces to /.
• Un-skipped: both HandleExceptionAsync_Detects… tests previously skipped as "NavigationManager cannot be mocked" now run, asserting navigation occurred with forceLoad and the requested scope present.

The existing GetAuthProperties_CoercesNonLocalReturnUrls theory is untouched and still pins the endpoint's strict validation — the flow now composes: handler sends local, endpoint accepts local. All 37 tests in the Blazor test namespace pass on net10.0.

Repro (before) / behaviour (after)

Blazor Server app without Microsoft.Identity.Web.UI, MapLoginAndLogout() mapped, incremental consent triggered from /admin/reports?tab=2:

• Before: returnUrl=https%3A%2F%2Fapp…%2Fadmin%2Freports%3Ftab%3D2 → IsLocalUrl false → RedirectUri = "/" → user lands on the app root after consent.
• After: returnUrl=%2Fadmin%2Freports%3Ftab%3D2 → IsLocalUrl true → user returns to /admin/reports?tab=2.

[Devon (DevonEast)]

@microsoft-github-policy-service agree