Support for localhost subdomains as redirect URI in AAD.

Question

Hello,

We have a multi-tenant app that make uses of subdomains to clearly identify the parts of our app that need auth and the other parts that don't.

• https://ourdomain.com
• https://app.ourdomain.com
• https://clientxyz.ourdomain.com

This cause no issues at all in production we can make use wildcards in the Authentication manifest in the Azure Active Directory admin center even though we understand that it is discouraged in the docs. We appreciate the flexibility.

The problem that we are facing is during the development. We use localhost URLs to mimic the above:

• http://localhost:3000
• http://app.localhost:3000
• http://clientxyz.localhost:3000

But we get the following error during the login flow:

AADSTS500117: The reply uri specified in the request isn't using a secure scheme.

It looks like the only option we now have is to serve our localhost URLs via https which is overkill since it's really not needed and an improvement to the regex can easily detect that these are still valid localhost URLs that simply have a subdomain.

We've tested using another OAuth2 provider and it works fine on their side.

Is there any way that you guys could improve this?

Many thanks

Answer 1

@Gabriel Labelle

This is currently a product limitation like you observed, but I've reached out the product group to see if there is a better workaround than the ones you mentioned or plans to improve this functionality. Like you said, Azure AD does not from authorization requests to non-HTTPS URLs, but http followed by localhost is the only exception. The https: scheme is required for any external domain name.

You can use your current workaround of serving your localhost URLs via https, or you can use a different domain name for your development environment that supports https.

As a security measure, Azure AD requires that redirect URIs use a secure scheme to prevent attacks.

I've reached out to the product team though to share your feedback and will update this thread accordingly if they are able to offer some better workarounds and updates on this functionality.

Switching to a different OAuth2 provider may work, but it may not have all of the security options offered by Azure AD.