MS Entra App Registration "Add Redirect URI" improperly rejects valid *.localhost subdomains with HTTP

Question

The Web Platform redirect URI validation in Microsoft Entra ID (formerly Azure AD) App Registrations is overly restrictive. It strictly requires http://localhost for local HTTP development and rejects valid subdomains like http://subdomain.localhost:3000/.

Steps to Reproduce

1. Navigate to the Microsoft Entra ID admin center.

Go to App registrations > select an application > Authentication.

Under platform configurations, add a Web platform (or edit an existing one).

1. In the Redirect URIs field, attempt to enter a loopback subdomain URL, such as: http://subdomain.localhost:3000/admins/auth/microsoft/callback

Observe the validation error: Must start with "HTTPS" or "http://localhost"

Expected Behavior The validation logic should accept http://*.localhost alongside http://localhost. The entry should be saved successfully, allowing developers to use wildcard localhost domains for testing OAuth flows locally.

Actual Behavior The UI blocks the input, completely preventing the developer from saving the valid local redirect URI unless they use https:// or strictly http://localhost.

Suggested Fix

Update the frontend and backend validation RegEx for Redirect URIs to permit http://*.localhost as a safe, local development URL, matching the security models already adopted by Microsoft Edge and the W3C.

---

Why this can be considered a bug

The current validation rule is technically outdated and disrupts standard modern web development workflows, particularly for multi-tenant SaaS applications. Here is the technical justification for updating this validation:

IETF Standard Compliance: According to RFC 6761 (Special-Use Domain Names), Section 6.3, the .localhost TLD is strictly reserved for loopback routing. Any subdomain of .localhost is guaranteed by network standards to resolve to the local machine safely.

Browser "Secure Context" Parity: For years now, all major browsers (including Microsoft Edge, Google Chrome, and Firefox) have treated http://*.localhost as a completely valid Secure Context. Browsers natively resolve these subdomains to loopback addresses without requiring hosts file modifications.

Modern Developer Workflows: Today, building multi-tenant web applications locally heavily relies on tenant-specific subdomains (e.g., tenant-a.localhost, tenant-b.localhost). Because Microsoft Entra blocks these, developers are forced into time-consuming and unnecessary workarounds, such as:

• Creating self-signed certificates and manually trusting local CAs to force https://*.localhost.
• Using third-party proxy tunnels (like ngrok) purely to bypass this frontend validation.

Answer 1

Hey @Rafael Sales,

I hear you needing tenant-scoped subdomains on localhost for your local OAuth flow is a very common modern-dev scenario, and the portal blocking http://subdomain.localhost… can be frustrating. As odd as it feels, the “Must start with HTTPS or http://localhost” error you’re seeing is actually an intentional, by-design restriction in the Azure portal’s current URI validation logic. Here’s the scoop:

1. Why only “http://localhost” is allowed for HTTP
   • Per the official docs (Redirect URI/supported schemes), HTTP schemes are supported only for the literal localhost domain. Although browsers and RFC 6761 treat any *.localhost as loopback, Azure’s portal validation hasn’t yet been updated to accept wildcards or subdomains under .localhost.
   • You can register http://localhost, http://localhost:3000/abc (paths and ports are okay), but http://sub.localhost (even on port 3000) will be rejected.
2. Workarounds today
   • Switch to HTTPS locally. You can generate a self-signed cert for your *.localhost subdomain and trust it in your dev machine. Then register https://subdomain.localhost:3000/... in the portal.
   • Use the loopback IP 127.0.0.1 in the manifest. You can add http://127.0.0.1:3000/… by editing the app’s manifest (replyUrlsWithType), but that only helps if you can route your subdomain traffic to 127.0.0.1 via hosts file or a local proxy.
   • Use a tunneling tool (ngrok, localtunnel) and register the secure HTTPS forwarding URL in the portal.
3. Why Microsoft hasn’t opened up wildcard-localhost yet
   • Service-side validation is intentionally conservative for App Registrations to prevent unsafe redirects in production scenarios. Today the portal doesn’t distinguish sandbox vs. prod in that validation logic.
4. Next steps / Ask the product team to reconsider
   • You can file a feature request on Azure Feedback (https://feedback.azure.com) asking for support of http://*.localhost as a safe loopback pattern. The linked standards (RFC 6761) and browser behavior all back this up, so the ask is reasonable.

Hope that helps explain what’s happening under the covers and gives you some options to unblock your local multi-tenant flow.

Answer 2

Kindly post a feature request for this here https://feedbackportal.microsoft.com/feedback/
so that it can get a chance to be implemented.