What the error actually says
AADSTS75005 carries the internal name Saml2MessageInvalid. Entra ID received
something at its SAML endpoint that it could not accept as a SAML 2.0 protocol
message.
Note the direction: this is about the request your application sends, not about the assertion Entra returns. If the user never sees a credential prompt, you are on the request side of the exchange.
How to tell this apart from a certificate problem
This is the distinction that saves the most time:
| Symptom | Where the fault is |
|---|---|
| Fails before any login prompt | The AuthnRequest your app sent |
| Fails after entering credentials | The assertion, its signature, or its audience |
AADSTS75005 is firmly in the first row. A rotated or expired signing
certificate cannot produce it, so certificate checks are not the place to start.
Causes, in the order they actually occur
1. Unsupported elements in the AuthnRequest.
Entra supports a subset of SAML 2.0. Requests carrying Subject, certain
Conditions, or unsupported NameIDPolicy values are rejected outright.
2. Wrong binding. Sending a request over a binding the endpoint does not accept — most often POSTing to the Redirect endpoint or vice versa. The metadata lists which bindings each endpoint supports; they are not interchangeable.
3. Malformed or badly encoded request. With HTTP-Redirect binding the request must be DEFLATE-compressed then base64 encoded then URL encoded, in that order. Skipping the compression step is a common bug in hand-rolled integrations.
4. Request sent to the wrong endpoint. A WS-Federation endpoint will not accept a SAML 2.0 message, and the two URLs look similar enough to be confused.
Confirming it
Capture the actual request — a browser network trace with “preserve log” enabled
will show the SAMLRequest parameter. Decode it (URL decode, base64 decode,
inflate) and read the XML. Comparing what you sent against the bindings your
IdP’s metadata advertises usually finds it in one pass.
Check what your metadata advertises to see the exact endpoints and bindings, decoded from the document.
Fixing it
- Strip unsupported elements from the request. If you built the request by hand, the shortest path is often to move to a maintained SAML library.
- Match the binding to the endpoint from the metadata rather than assuming.
- Verify the encode order for redirect binding: deflate, base64, URL encode.
When it appears out of nowhere
An integration that worked for a year and then started returning AADSTS75005
usually means the IdP’s endpoints changed and your configuration still points at
the old shape. Endpoint drift is silent in exactly the same way certificate
rotation is: the document changes, nobody reads it, and the first signal is a
failure.