AADSTS750054 fix: SAML request missing from the sign-in URL

What does AADSTS750054 mean?

Microsoft’s description:

SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding. To learn more, see the troubleshooting article for error AADSTS750054.

The reference table gives this code no PascalCase name.

In SAML single sign-on the app (the service provider) sends an authentication request to Entra. Microsoft’s SAML protocol page says “the cloud service (the service provider) uses an HTTP Redirect binding to pass an AuthnRequest (authentication request) element to Microsoft Entra ID”. With that binding the request travels in the URL as a SAMLRequest query parameter. If Entra’s SAML endpoint is reached and that parameter isn’t in the URL, it returns 750054.

Microsoft’s troubleshooting article gives the cause: “Microsoft Entra ID wasn’t able to identify the SAML request within the URL parameters in the HTTP request. This can happen if the application is not using HTTP redirect binding when sending the SAML request to Microsoft Entra ID.” It lists three common issues:

1. Single sign-on isn’t enabled on the application side.
2. The app only supports IdP-initiated SSO. Microsoft: “[When] entering a sign-in URL for an application that only supports identity provider-initiated single sign-on can lead to a bounce back from the application without a SAML response.”
3. The sign-on URL is wrong.

What users report: Auth0, set up as the SAML service provider, sends the request with HTTP POST binding when its Protocol Binding field is set, and gets 750054 until the field is cleared or set to HTTP-Redirect. A DocuSign SSO setup on Microsoft Q&A hit it during testing.

Related SAML codes with their own page:

• 76021: the request arrived but isn’t signed, and the app requires signed requests.
• 75011: the request arrived but asks for an authentication method the session doesn’t match.

With 750054 the request didn’t arrive in the URL at all, so nothing in it was checked yet.

Is it an attack?

No. The request carries no SAML message, so there is nothing to sign anyone in with. It points at a broken SSO setup.

Pattern	Likely meaning
Every user of one SAML app, from the day SSO was set up	Wrong binding in the app (HTTP POST instead of HTTP Redirect), or the wrong sign-on URL.
Users who start from the My Apps tile or a bookmark, but not from the app	The Sign on URL in Entra points at something that doesn’t produce a SAML request, such as an app that only supports IdP-initiated SSO. Our reading of Microsoft’s second cause.
One user, once	A stale bookmark or a reloaded page on the SAML endpoint. Likely, but unconfirmed.

How do I find it in my logs (KQL)?

Microsoft doesn’t document whether 750054 is written to the sign-in logs. We assume that without a SAML request Entra may not know which app was meant, so there may be no row, or a row with little app detail. Check first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "750054"
| summarize Rows = count() by SourceTable

If rows exist, see which apps and protocols they belong to. Microsoft documents AuthenticationProtocol with the possible values “none, oAuth2, ropc, wsFederation, saml20, deviceCode”:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "750054"
| summarize Rows = count(), Users = dcount(UserPrincipalName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppDisplayName, AppId, AuthenticationProtocol
| sort by Rows desc

If nothing comes back, use the correlation ID and timestamp from the user’s error page. ResultType is a string column, so compare it with "750054", not 750054.

How do I fix AADSTS750054?

For the user: start the sign-in from the app’s own address. If the error comes from a tile in My Apps, tell your IT helpdesk which tile.

For admins:

1. In the Microsoft Entra admin center, open Enterprise applications, the app, then Single sign-on.
2. Check the Sign on URL. It must be a URL in the app that starts SSO and sends a SAML request. If the app only supports IdP-initiated SSO, Microsoft says a sign-on URL can cause the bounce back that ends in 750054.
3. Check with the vendor that SSO is enabled on the app side.
4. Select Test this application, paste the error into Resolving Errors and choose Get resolution guidance, as Microsoft’s troubleshooting article describes.

For developers and app vendors: send the AuthnRequest with HTTP Redirect binding, encoded into the URL as the SAML bindings specification describes, which Microsoft’s article links. If your SAML library has a binding setting, set it to HTTP-Redirect. Users report that this is the fix for Auth0.