.NET 11 for Duende IdentityServer Developers

.NET 11 and C# 15 will be released this November and with it comes changes, updates, and new features. Of course every new update brings the same familiar question, what changes for the software I maintain? For developers of Duende IdentityServer applications, the short answer is, not a whole lot. Like every year, there are some features to think through and test when choosing to upgrade.

The biggest considerations in the ASP.NET Core in .NET 11 RC1 release notes are registration confirmation in applications using the default ASP.NET Core Identity UI, refreshed authentication state in Blazor, and optional SignalR authentication refresh. The impact depends on what you move to .NET 11: your IdentityServer host, a connected application, or both.

Updated: September 9, 2026.

Can a .NET 11 application use .NET 10-targeted IdentityServer packages?

Yes! A net11.0 application can reference net10.0 library assets. A package's target framework describes the APIs it was compiled against, and does not tie the consuming application to that runtime version. Microsoft's target framework documentation explains how NuGet and the SDK select compatible assets.

For an IdentityServer host, that means you can target .NET 11 while referencing the .NET 10-targeted IdentityServer packages. The host runs on ASP.NET Core 11, so framework behavior can change beneath those packages. Setting a library’s <TargetFramework> to net10.0 but using it in a .NET 11 process, will keep the API structure and use the behavior of the .NET 11 runtime.

To simplify Duende IdentityServer maintenance and support, there are currently no plans to create .NET 11-targeted packages. This leaves you with the important question, what changes when I update my Duende IdentityServer to use .NET 11 packages while still using the .NET 10 IdentityServer packages? tl;dr Registration, authentication state, and session continuity deserve attention even when your IdentityServer package version stays the same. More on these below.

Which .NET 11 RC1 changes affect IdentityServer customers?

The following changes apply to components that adopt .NET 11, not to every application connected to IdentityServer. Running IdentityServer does not mean you use the default ASP.NET Core Identity UI, Blazor, or Windows authentication.

When does the ASP.NET Core Identity registration change matter?

In .NET 11 RC1, the default ASP.NET Core Identity UI honors every configured sign-in confirmation requirement after password or external registration. If your IdentityServer host uses that UI and moves to .NET 11, test registration even if you retain the same IdentityServer packages. Only upgrading a separate client does not change registration pages hosted on an unchanged identity server.

The relevant settings are:

• SignInOptions.RequireConfirmedEmail
• SignInOptions.RequireConfirmedPhoneNumber
• SignInOptions.RequireConfirmedAccount

For example, an application that requires a confirmed phone number can send a new registrant to registration confirmation instead of completing sign-in. If your onboarding flow never gives that user a working way to confirm their phone number, registration becomes a dead end.

This is an ASP.NET Core Identity UI change, not a blanket IdentityServer behavior change. The ASP.NET Core Identity integration connects your user store to IdentityServer, but it does not imply that you use Microsoft's default registration pages. Custom pages and previously scaffolded pages contain application-owned code that you must inspect separately.

If any changes affect your UI, fix the user’s journey, not the symptom. Test password registration and also first-time registration through an external provider. Verify confirmation-message delivery, expired links, resend behavior, phone verification where required, and the eventual return to the requesting client.

Microsoft documents disabling the confirmation settings as a way to permit immediate sign-in. That changes your security policy beyond registration. Do not turn those settings off merely to restore the old onboarding experience. There is no compatibility switch that keeps confirmation mandatory for later sign-ins while bypassing it only during registration.

Add a test that makes the intended behavior explicit. A user who has not met your confirmation policy must not receive an authenticated application session.

Can .NET 11 clients use an existing IdentityServer deployment?

The benefit of running on top of an open standard means applications target the standard, not a specific binary version. OpenID Connect (OIDC) and OAuth 2.0 do not require clients, APIs, or the authorization server to run the same .NET version. You can also upgrade a client or API independently while leaving the IdentityServer host unchanged. Check the support requirements of the libraries used by each application and verify its integration before production deployment.

The RC1 notes do not announce any token-format change or require you to replace client registrations. For example, you can evaluate a Blazor application's move to .NET 11 while leaving IdentityServer on its existing supported runtime. Test sign-in, token use, and logout across that boundary rather than combining both deployments into one upgrade.

If nothing in your deployment changes, these release notes alone do not require a configuration change, key rotation, or session migration. Continue applying supported security and maintenance updates independently of any .NET 11 evaluation.

What does Blazor authentication refresh change?

For a Blazor application moving to .NET 11, Interactive Server components can receive a refreshed ClaimsPrincipal without reconnecting the circuit. RC1 enables authentication refresh for the Blazor component hub and client without additional configuration. After a successful refresh, Blazor updates authentication state and raises AuthenticationStateChanged components such as AuthorizeView re-render against the refreshed identity. This is a change in the client application, not a new IdentityServer feature.

This is useful for long-running applications, but some applications make the assumption the user, and their claims, stay fixed for the lifetime of a circuit.

Audit circuit-scoped services and components that cache a user ID, tenant selection, permissions, or loaded records. A changed authentication state must not leave the previous user's data visible or usable. Reload or clear user-specific state when the identity changes. And verify that sensitive server-side operations still perform authorization checks. Hiding a button with AuthorizeView is not access control for the underlying operation.

Test a long-lived circuit across role removal, session expiration, sign-out, and signing in as a different account in another tab. Check both rendered content and subsequent operations.

Remember that authentication refresh is not a push notification from IdentityServer. Blazor still needs the application's authentication mechanism to supply an updated principal. A role edit in your user database does not, by itself, rewrite an existing token or cookie. Keep your claims-renewal, revalidation, and revocation policies in the test plan.

Does SignalR authentication refresh replace OAuth token refresh?

No. SignalR authentication refresh updates the authentication attached to an existing connection. Your application still needs to obtain a valid access token from the appropriate token-acquisition mechanism. A hub accepting IdentityServer-issued tokens can evaluate this feature independently of the IdentityServer host's runtime.

RC1 finalizes the server and .NET client APIs and adds TypeScript client support. For your own hubs, the server opts in with EnableAuthenticationRefresh. Clients can schedule refreshes or request one after acquiring updated claims. This can avoid a reconnect when an expiring token would otherwise cause the connection to close.

Before adopting the feature:

• Verify that .NET AccessTokenProvider or Javascript accessTokenFactory returns a usable token rather than a cached, expired value.
• Define the identity transitions your hub permits. Use OnAuthenticationRefresh to reject transitions your application cannot safely handle. For a single-user connection, compare a stable subject within a validated issuer. Apply tenant constraints where relevant.
• Reassess group memberships and application-cached permissions when claims change. A new principal alone does not establish your application's authorization policy for existing subscriptions.
• Test token-acquisition failure, denied refresh, expiration, and reconnect through your production transport or managed SignalR service. Framework support alone does not establish support in every service configuration.

Review CloseOnAuthenticationExpiration alongside refresh behavior. Do not extend access-token lifetimes just to mask refresh failures, and don’t move server-held tokens into browser JavaScript to copy the TypeScript example.

If you adopted Preview 7, move refresh callbacks from AuthenticationRefreshOptions to the HubConnection.AuthenticationRefreshed and HubConnection.AuthenticationRefreshFailed events. RC1 also moves AuthenticationRefreshContext to Microsoft.AspNetCore.Connections.Features and replaces IConnectionUserRefreshFeature with IConnectionAuthenticationRefreshFeature. These are preview-to-preview migrations, not edits required in every .NET application.

Will Negotiate TLS channel binding disrupt Windows sign-in?

RC1 supplies a Transport Layer Security (TLS) endpoint channel binding token to the Kerberos or NTLM exchange when Negotiate authentication runs over HTTPS on Kestrel. Microsoft says no configuration changes are required. Connections without an available channel binding token retain the existing behavior.

For IdentityServer customers, this matters when a host or sign-in component moving to .NET 11 uses Negotiate authentication on Kestrel. Include Windows sign-in integrations in your host's regression tests. The change does not apply to ordinary OIDC or bearer-token authentication.

Test through the same proxy, TLS termination, certificates, and Windows authentication setup used in production. A direct localhost test does not exercise that topology. Forwarded HTTPS headers do not create a TLS channel binding token on an unencrypted connection to Kestrel. Do not assume this change provides end-to-end channel binding across a TLS-terminating proxy, or disable security checks preemptively to avoid a hypothetical failure.

How do you preserve sessions when targeting .NET 11?

Preserve access to keys and operational state in each application you deploy, including the IdentityServer host if you retarget it. A client's local authentication session is distinct from the IdentityServer session. Losing access to cookie-protection keys or session storage in either application can disrupt sign-in, regardless of whether its NuGet package versions changed.

RC1 fixes thread-pool starvation during a forced Data Protection key-ring refresh and an IIS shutdown hang when preload is enabled. These are framework fixes that matter to IdentityServer hosts as well as clients running on the affected framework. Neither fix is an instruction to replace keys or migrate sessions.

For the application you deploy, follow the ASP.NET Core Data Protection deployment guidance: persist the key ring durably, share it between instances of the same application, and retain access to the certificates or services that protect it. This does not mean sharing one key ring or application identity between unrelated clients and IdentityServer.

Keep the existing application discriminator stable. If you use SetApplicationName, do not rename it during deployment. If you currently rely on a derived name, investigate its effective value before introducing an explicit one. Changing that value can make existing protected data unreadable even when the key files are present.

Data Protection keys and IdentityServer signing keys serve different purposes. Preserve both stores when deploying the identity server, along with its persisted grants and server-side sessions where configured. A runtime change is not a reason to delete those records. Preserve each client's token and session stores, too.

Prove continuity in staging: sign in before deployment, deploy the new build, then use the existing session and refresh token. Repeat after rolling back. For a rolling deployment, test old and new instances together rather than assuming that shared storage alone guarantees compatibility.

Should you enable Device Bound Session Credentials now?

Not yet. Device Bound Session Credentials (DBSC) is an experiment in Microsoft.AspNetCore.Authentication.DeviceBoundSessions. Microsoft says the package will remain prerelease throughout .NET 11 and until the specification stabilizes. Browser support also requires an experimental implementation. DBSC is not a requirement for using IdentityServer with .NET 11 applications.

DBSC binds session refresh to a private key held by the browser. An attacker with a copied short-lived cookie can still use it until it expires, but cannot extend the session without the device key.

That protection concerns cookie-session renewal. It is not the same as Demonstrating Proof of Possession (DPoP), which binds OAuth tokens to a key. DBSC does not turn an IdentityServer-issued access token into a sender-constrained token.

If you evaluate DBSC in a client application, test browser support, fallback, sign-out, renewal failures, and that application's cookie scheme. Protecting the client's cookie does not also protect the separate IdentityServer session cookie. Microsoft's generic cookie example is not an IdentityServer integration recipe, and the release notes do not establish Duende Software support for that integration.

Which smaller breaking changes should you check?

The remaining RC1 changes mainly affect UI, preview adopters, and API tooling in applications moving to .NET 11. They are not required for an unchanged IdentityServer host.

• Bootstrap 4 Identity UI: IdentityUIFrameworkVersion=Bootstrap4 now produces an MSBuild warning. Select Bootstrap5, or remove the property to use the default. Check custom layouts, styles, scripts, and accessibility. Changing the property does not rewrite your scaffolded markup.
• Validation localization: Preview 7 adopters must remove ValidationOptions.MessageKeyProvider and update resource keys to the RC1 conventions. For example, a shared required-field message can use RequiredAttribute_Error. Test localized registration and account-management forms that use Microsoft.Extensions.Validation; do not assume this rewrites every MVC validation setup.
• Blazor browser options: Preview configuration names become InteractiveServer, StaticServer, and InteractiveWebAssembly. Update code using the previous names and test reconnect behavior.
• Kestrel chunked parsing: Remove any code enabling the preview-only Microsoft.AspNetCore.Server.Kestrel.InsecureChunkedParsing switch. There is no replacement. Fix senders producing invalid requests rather than trying to restore insecure parsing.
• OpenAPI generation: [Obsolete] now generates deprecated: true. Review document diffs and generated clients for custom APIs. If using build-time generation, deliberately choose OpenApiGenerationEnvironment and keep build-time startup away from production secrets and side effects. These changes concern generated API descriptions, not IdentityServer's OIDC discovery document.

What should IdentityServer users do when .NET 11 is released?

Identify which processes will run on .NET 11, then test their framework-dependent behavior and authentication flows. Keep runtime changes and optional feature adoption separate so failures are easier to isolate.

1. Identify what it looks like to move to .NET 11. List the IdentityServer host, clients, APIs, hubs, and account-management applications. Components sharing the host process use that process's runtime, even when their packages target .NET 10. Independently deployed clients and APIs do not need to upgrade at the same time as IdentityServer.
2. Check dependencies in each changing application. Verify compatible package assets and published runtime support for IdentityServer, authentication handlers, token-management libraries, and database providers. Do not assume that all package major versions must match the application's .NET version, or that successful restore proves runtime behavior.
3. Review the whole application upgrade path. Review earlier .NET 11 previews and the runtime and Entity Framework Core breaking changes. RC1 notes are incremental. For example, Preview 6 introduced cross-origin request protection; include external-provider POST callbacks in your tests rather than globally disabling protection. If you also change IdentityServer package versions, follow the IdentityServer upgrade guides for specific API and store migrations. Treat those as distinct from the runtime change.
4. Exercise real authentication flows. Cover registration, confirmation, login, external login, authorization code flow with Proof Key for Code Exchange (PKCE), refresh tokens, client credentials, and logout. Verify discovery and published signing keys as well as end-to-end token issuance and validation.
5. Rehearse application continuity and rollback. Test existing cookies, token storage, Data Protection, database compatibility, and long-lived connections. For an IdentityServer host deployment, include existing persisted grants, signing keys, and server-side sessions. Establish how traffic returns to the previous application build without relying on a destructive database restore.
6. Roll out against a baseline. Monitor registration completion, login and token endpoint failures, latency, cryptographic errors, and reconnect rates. Keep passwords, cookies, and raw tokens out of logs. Define rollback thresholds before moving traffic.

The practical impact of .NET 11 comes from the framework running your application, not just the target printed on a package. When targeting .NET 11 with .NET 10-targeted IdentityServer packages, prioritize registration confirmation, session continuity, and any Windows sign-in integration in the host. If using Blazor, test its authentication state and SignalR refresh where you use them. And keep experimental session features separate.

For questions about a particular product/runtime combination, you can view supported versions in our documentation. Or you can contact us through the Duende Software support channels.