Azure AD federation metadata, with or without authentication
When working with cloud services, you occasionally encounter two APIs that essentially do the same thing, but require different authentication or permissions. Such cases tend to pique my interest – not only because there might be a security issue lurking, but also because there’s often an interesting story behind these APIs.
One case I recently ran into is Azure AD federation metadata.
When you create an enterprise app in Azure AD and configure SAML-based single sign-on, the portal shows you a link to the federation metadata:
The link points to https://main.iam.ad.ext.azure.com/api/ApplicationSso/[Application-Id]/DownloadSamlMetadataV2
and requires a valid browser session.
For SAML applications, it’s quite common to download the IdP metadata and to then take the file and copy it to the application’s configuration. So the fact that the URL requires authentication isn’t surprising.
The portal also provides another URL that lets you download the same IdP metadata:
https://login.microsoftonline.com/[Tenant-Id]/federationmetadata/2007-06/federationmetadata.xml?appid=[Application-Id].
This URL provides you the exact same metadata, but does not require authentication.
Is this a security issue? Probably not – IdP metadata typically doesn’t contain any confidential information, so making it publicly available seems pretty harmless. In fact, other protocols like OpenID connect even require metadata to be publicly available:
OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer.
Still, it’s curious that Azure AD lets you access the same information in two ways, one requiring authentication and one that doesn’t.