3

When authenticating against an AzureAD instance (using WS-Federation and SAML 2 tokens) the relying/authenticating application requests authentication metadata from a fixed URL on the auth servers, that metadata contains multiple X509 certificates (containing only a public key).

When the app receives an authentication token (in my case a SAML2 token) it contains a digital signature that can be verified against the certificates received from the metadata service.

The chain of trust in the above scenario is maintained because the metadata service is accessible over https only, therefore we know that the certificates are owned by the owner of the hostname in the metadata service URL.

What I have noticed from looking at other AzureAD metadata endpoints (with no relation to mine) is that they contain the same set of signing certificates, i.e. it seems that by default all AzureAD instances use the same Microsoft certificates globally. Is this observation correct?

I wonder if the best practice would be to never rely on those certificates, after all, if they were compromised then every app relying on them across the world would be compromised simultaneously.

One alternative is to upload our own certificates to AzureAD, which adds a maintenance task to periodically update certificates as they approach expiry.

Another alternative is to install one or more certificates in the certificate store of the app server, i.e. not to use the certificates obtained from the metadata service. This seems like the most secure option as it doesn't rely on the extra link in the chain of trust (the https connection to the metadata service).

What is the best practice advice regarding authentication signing certificates in Azure AD and WS-Federation?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.