[Bug] MSAL.NET fails with localhost and non-localhost redirect URIs after 2025-10 cumulative update

[juanpgarces]

Library version used

4.77.1

.NET version

.NET 8

Scenario

PublicClient - desktop app

Is this a new or an existing app?

The app is in production, I haven't upgraded MSAL, but started seeing this issue

Issue description and reproduction steps

We're encountering a critical issue with MSAL.NET (version 4.77.1.0) in our .NET MAUI app following the October 2025 cumulative update for Windows. The update appears to break support for http://localhost redirect URIs, which previously worked reliably.

Context

• Environment: .NET MAUI app using MSAL.NET for interactive authentication
• Redirect URI used: nidclient://auth (custom scheme)
• MSAL version: 4.77.1.0
• Platform: Windows 11 (post-2025-10 cumulative update)

Problem
After switching from http://localhost to a custom URI scheme (nidclient://auth), MSAL throws the following exception:
MSAL.NetCore.4.77.1.0.MsalClientException:
ErrorCode: loopback_redirect_uri
Microsoft.Identity.Client.MsalClientException: Only loopback redirect uri is supported, but nidclient://auth/ was found. Configure http://localhost or http://localhost:port both during app registration and when you create the PublicClientApplication object. See https://aka.ms/msal-net-os-browser for details

This seems to contradict the guidance that custom URI schemes are supported in cross-platform scenarios like MAUI.

Related Discussions

• Microsoft Q&A: localhost not working anymore after 2025-10 cumulative update
• Stack Overflow: localhost applications failing after installing 2025-10 cumulative update

Questions

• Is there a workaround or patch planned to restore localhost support post-update?
• Can MSAL.NET be updated to support custom URI schemes like nidclient://auth on Windows?
• Is there a recommended redirect URI strategy for MAUI apps that works across platforms post-update?
  Thanks in advance for your guidance!

Relevant code snippets

var builder = AsyncHelper.RunSync(async () => PublicClientApplicationBuilder.Create(await connectionProviderService.GetClientID())
                    .WithB2CAuthority(await connectionProviderService.GetAuthoritySignIn())
                    .WithDefaultRedirectUri());

            return builder.Build();

Expected behavior

No response

Identity provider

Azure B2C Custom Policy

Regression

No response

Solution and workarounds

No response

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• [Bug] Problem with new version 4.61.1 #4783
• [Bug] Microsoft.Windows.Client does not work with WinUI (.Net 6.0) #4790
• [Bug] I'm getting "Only loopback redirect uri is supported" #4805

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Solution 1:

Add a reference to Microsoft.Identity.Client.Desktop and Microsoft.Identity.Client.Extensions.Msal (same version as MSAL). When constructing the PublicClientApplication, add .WithWindowsEmbeddedBrowserSupport(). If there are still issues with the redirect URI, set it explicitly via .WithRedirectUri. Example:

PublicClientApplicationBuilder PCAB = PublicClientApplicationBuilder.Create(_clientId);
_IdentityClientApp = PCAB
                    .WithWindowsEmbeddedBrowserSupport()
                    .Build();

Reference:

• [Bug] Microsoft.Windows.Client does not work with WinUI (.Net 6.0) #4790 (comment)
• [Bug] I'm getting "Only loopback redirect uri is supported" #4805 (comment)

Solution 2:

Use .WithEmbeddedWebViewOptions(new EmbeddedWebViewOptions()) instead of .WithWindowsEmbeddedBrowserSupport() if the latter is not feasible. This approach was confirmed to work for some users.

Reference:

• [Bug] Problem with new version 4.61.1 #4783 (comment)

Powered by issue-sentinel