🔐 Should You Include a Certificate in a SAML AuthnRequest?

#authentication

When implementing SAML authentication, one question often arises:

Should the Service Provider (SP) include its certificate directly in the <AuthnRequest>?

Why You Might Include the Certificate

Including the certificate inside the <ds:Signature> block of the AuthnRequest allows the Identity Provider (IdP) to verify the signature on-the-fly—even if it hasn’t been pre-configured with the SP’s metadata. This can be useful in:

Dynamic Federation : When the IdP supports just-in-time registration of SPs.
Certificate Rotation : When the SP wants to switch to a new cert without coordination delays.
Multi-tenant Platforms : Each tenant may use different certs, making dynamic verification necessary.

Here’s how it looks in the AuthnRequest:

<ds:KeyInfo>
  <ds:X509Data>
    <ds:X509Certificate>MIIDazCCAlOgAwIBAgIU...</ds:X509Certificate>
  </ds:X509Data>
</ds:KeyInfo>

The Risks

However, including the certificate comes with security concerns :

Trust Issues : If the IdP trusts any certificate in the request, it’s open to spoofing. Malicious actors could generate their own cert and sign forged requests.
Bypassing Metadata : It undermines static trust relationships typically built through SAML metadata exchange.
Validation Required : The IdP must enforce certificate whitelisting, thumbprint matching, or trusted CA validation.

Best Practices

Use this approach only if the IdP has logic to validate the certificate (e.g., by thumbprint or CA).
Avoid in static integrations where both parties pre-share metadata.
Prefer exchanging trusted certificates via SAML metadata , which also supports expiry dates, rollover, and entity validation.