[release/10.0] Preserve antiforgery token

[github-actions]

Backport of #64806 to release/10.0

/cc @javiercn @ilonatommy

Preserve antiforgery token

Fix antiforgery token trimming in Blazor WebAssembly prerendering

Description

When a Blazor WebAssembly app with Individual Identity authentication is published with PublishTrimmed=true, the antiforgery token persisted during SSR is not restored during the SSR-to-WASM handoff. This causes the <AntiforgeryToken> component to render nothing in interactive mode, breaking form submissions.

Root cause: The IL trimmer removes DefaultAntiforgeryStateProvider.CurrentToken property and AntiforgeryRequestToken constructor because they're only accessed via reflection by the persistent state system.

Fix: Add [DynamicDependency(JsonSerialized, typeof(...))] attributes on WebAssemblyHostBuilder.InitializeDefaultServices() to preserve:

• DefaultAntiforgeryStateProvider - ensures the [PersistentState] CurrentToken property is preserved
• AntiforgeryRequestToken - ensures the constructor and properties are preserved for JSON deserialization

Fixes #64693

Customer Impact

Customers publishing Blazor WebAssembly apps with Individual Identity authentication experience is broken form submissions because the antiforgery token is not properly restored after SSR-to-WASM handoff. This is a critical issue affecting production deployments with trimming enabled.

Regression?

• Yes
• No

Regressed from .NET 9. In .NET 9, the antiforgery token was retrieved using PersistentComponentState. In .NET 10, it was changed to use the [PersistentState] attribute on DefaultAntiforgeryStateProvider.CurrentToken. The new declarative model for persisting state causes the IL trimmer to remove the necessary types since they're only accessed via reflection.

Risk

• High
• Medium
• Low

The fix adds DynamicDependency attributes to preserve specific types from IL trimming. This is a minimal, targeted change following established patterns already used elsewhere in the codebase. It only affects the trimmer behavior and has no runtime logic changes.

Verification

• Manual (required)
• Automated

Manual testing with a Blazor WebAssembly app using Individual Identity authentication to verify form submissions work correctly.

Packaging changes reviewed?

• Yes
• No
• N/A

No packaging changes in this PR.

---

Existing workarounds

<linker>
	<!--  AntiforgeryRequestToken deserialization issues  -->
	<assembly fullname="Microsoft.AspNetCore.Components.Web">
		<type fullname="Microsoft.AspNetCore.Components.Forms.AntiforgeryRequestToken" preserve="all"/>
	</assembly>
	<assembly fullname="Microsoft.AspNetCore.Components.WebAssembly">
		<type fullname="Microsoft.AspNetCore.Components.Forms.DefaultAntiforgeryStateProvider" preserve="all"/>
	</assembly>
</linker>

[dotnet-policy-service]

Hi @@github-actions[bot]. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[ilonatommy]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.