The SAML signature was valid. That was never the problem.

SAML single sign-on has a replay problem built into its shape, and most service providers "solve" it in the one place an attacker can reach.

Here is the setup. You are the service provider. A user lands on your login, you send an AuthnRequest to their identity provider, and that request carries a random ID. The IdP authenticates the user and posts back a SAML Response with InResponseTo="<that ID>". You look up the ID, confirm you actually issued it, and consume it so it can never be used twice. Request bound to response, response used once, replay defeated. Textbook.

Now the question that breaks it: what did the IdP actually sign?

Not the Response. The Assertion. Entra, Okta, most of the field sign the <Assertion> element and leave the <Response> envelope around it unsigned. That is normal, and the spec allows it. But InResponseTo lives on the <Response>. So the field your entire replay defense keys off is the one field the signature does not cover. You can edit it, delete it, do whatever you like to it, and the assertion's signature still validates perfectly, because you never touched the assertion.

So watch what happens when an attacker does the obvious thing.