AADSTS50008: SAML token is invalid

What the error actually says

AADSTS50008 carries the internal name SamlTokenInvalid. Entra ID received a SAML assertion from a federated identity provider and refused it. The important detail is where the rejection happens: Entra is the relying party here, and the token was produced by something else — an on-premises AD FS farm, a third-party IdP, or another tenant.

That means the fault is almost never in Entra’s configuration. It is in what the issuing side signed the assertion with, or when.

Causes, in the order they actually occur

1. The signing certificate rotated and Entra still trusts the old one. Federation trust in Entra pins the issuing certificate. When the IdP rotates and nobody updates the trust, every assertion signed by the new key is rejected. This is the majority case, and it usually lands on a Monday because the rotation ran over the weekend.

2. The signing certificate expired. Same failure, different trigger. The IdP kept signing with a certificate whose notAfter has passed.

3. The certificate is not yet valid. A rotation brought forward too far: the new certificate has a notBefore in the future, so nothing is currently signable. This produces the same generic error and takes far longer to diagnose because the certificate looks fine in a portal listing.

4. Clock skew between the issuer and Entra. The assertion’s NotBefore / NotOnOrAfter conditions fall outside Entra’s tolerance. Rare, and worth checking only after the certificate is ruled out.

Confirming it in under a minute

Pull the issuing IdP’s metadata and look at the signing certificates directly:

• Every notBefore and notAfter on the signing keys
• Whether more than one signing certificate is published — during a correct rotation there will be two, and the new one may not be valid yet
• Whether the certificate Entra trusts is still in the document at all

Run a free check against your metadata URL and you get exactly those fields, decoded, with the day count.

Fixing it

Once you know which of the four causes applies:

• Rotated key: update the federation trust in Entra with the new signing certificate. For AD FS, Update-MgDomainFederationConfiguration (or the older Update-MsolFederatedDomain) refreshes it from the farm.
• Expired key: rotate at the IdP first, then update the trust. Do not simply extend the old certificate if the IdP has already moved on.
• Not yet valid: either bring the notBefore forward at the IdP, or keep the previous certificate active until the new window opens. There must be no gap.
• Clock skew: fix time sync on the issuing servers.

Why this keeps happening

Nothing in the protocol tells the relying party that a rotation is coming. The IdP publishes a new certificate in its metadata and, if nobody is reading that document, the first signal is a failed login. Reading the metadata on a schedule turns this class of outage into a calendar entry.