Azure AD app wildcard Reply URL

Azure AD apps (a.k.a Azure Active Directory apps, a.k.a AAD apps) are an essential component when interacting with Office 365 data outside of SharePoint – Mail, Calendar, Groups, etc.

As an O365 developer I have found myself writing JavaScript code against AAD apps (using ADAl.js) and often, especially during development, found myself entering a long list of Reply URLs. Reply URLs must be specified for any location from which authentication to AAD occurs. From a practical standpoint this results in someone (an Azure Administrator) having to update the list of Reply URLs every time a web part is inserted into a page or a new site is provisioned which relies on an Azure AD app.

If this is not done, the user is redirected to Azure login failure with ‘The reply address … does not match the reply addresses configured for the application’.

Error when Reply URL is not correctly specified
Error when Reply URL is not correctly specified

Perhaps the following is documented elsewhere but I have not come across it – a Reply URL can be specified using wildcards!

Using a wildcard Reply URL when configuring an AAD app
Using wildcard Reply URLs when configuring an AAD app

Probably the most common use for this is to end a Reply URL with an asterisk (wildcard) which will permit any URL which begins with the characters preceding it.

This example would support any URL coming from any page in SharePoint Online from within the named tenant.

It is also possible to use the wildcard character elsewhere in the Reply URL string.
e.g. https://**
This example would support any URL coming from any page in SharePoint Online from within *any* tenant.

Armed with this knowledge, be responsible and limit strictly how it is utilised. The implementation of Reply URL is a security feature and it is important that only trusted locations are allowed to interact with your app. I recommend only using wildcard Reply URLs in development environments.


Published by

Paul Ryan

As a developer my professional interests are technical and tend to be SharePoint focused. I've been working with SharePoint since 2009 and hope my posts will give back a little to the community that's supported me over this time. I'm also a keen runner (half-marathon) and passionate Brompton bicycle owner.

14 thoughts on “Azure AD app wildcard Reply URL”

  1. Posted a ticked to the azure support to find out if wildcards are officially supported, and got the following reply from them:

    > …for the moment wildcards are only allowed in redirect urls and not supported. Cannot say what will happen, couldn’t get more in this matter.

    > Though wildcards are allowed in redirect urls, they are not secure, not OIDC protocol compliant and will not be supported in our converged (V2) app model.

    Allowed, but not officially supported, could be dropped at any moment.

    1. Thanks for posting. I agree that a wildcard Reply URL should be used with care, and not in production. However, I find this very useful during development.

  2. I’m trying to create a AAD App to auth with Graph API, like I did a lot of times, but on new tenants the wildcards are not working…
    Is it discontinued?

  3. Hi Paul,
    Thanks for sharing this post. I can understand that wildcards in the domain & subdomain of the reply urls like “https://*” could be serious. I am trying to figure out what is the security vulnerability if I use a wildcard reply URL like “*” ?

    1. Hi, I’m not aware of a reason why this could cause a security issue – seems okay to me. Nevertheless, I understand that wildcards are considered poor practice in production systems.

  4. Hi Paul. If wildcards are a poor practice, what do you suggest for supporting multiple tenants for the reply url?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.