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’.
Perhaps the following is documented elsewhere but I have not come across it – a Reply URL can be specified using wildcards!
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.
e.g. https://tenant.sharepoint.com/*
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://*.sharepoint.com/*
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.
Paul.
I don’t think this works anymore
It worked for me yesterday!
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.
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.
Thank you very much for this. I’ve spent hours trying to get the reply url to work.
Glad to hear this 🙂
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?
Not as far as I am aware – but as wildcard reply URLs are inherently less secure this wouldn’t surprise me.
Hi Paul,
Thanks for sharing this post. I can understand that wildcards in the domain & subdomain of the reply urls like “https://*.sharepoint.com” could be serious. I am trying to figure out what is the security vulnerability if I use a wildcard reply URL like “https://myapp.domain.com/*” ?
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.
Starting at version 2 of the API this is not supported anymore.
https://stackoverflow.com/questions/47520604/why-is-redirect-url-fully-qualified-in-azure-ad-b2c
Hi Paul. If wildcards are a poor practice, what do you suggest for supporting multiple tenants for the reply url?
This is handy when in development. Once in production the supported tenants should be known and specified if possible
Thanks for sharing all of your experiences!