The AADSTS750056 SAML message was not properly base64 encoded error means Azure AD received a SAML request or response in the wrong encoded format.
When sign-in through SAML suddenly stops with the page that says “Sorry, but we’re having trouble signing you in” and AADSTS750056, it usually points to a problem with how the SAML message is built and encoded before it reaches Microsoft Entra ID (Azure AD). The good news is that this error behaves in a repeatable way, and once you trace where the encoding breaks, you can remove it for good.
Understanding The AADSTS750056 SAML Message Was Not Properly Base64 Encoded Error
This error comes from the Microsoft identity platform when it receives a SAMLRequest or SAMLResponse that does not match the Base64 rules expected by the SAML endpoint. Instead of a clean decoded XML payload, Azure AD ends up with bytes that cannot be decoded, so it stops the sign-in flow and shows the AADSTS750056 message.
In a normal SAML flow, the service provider or application creates an AuthnRequest XML document, compresses it with the DEFLATE algorithm if the HTTP Redirect binding is used, encodes the result in Base64, then URL encodes that string. For HTTP Post binding, the message is usually just Base64 encoded. Any shortcut or mistake in this chain can trigger the aadsts750056 saml message was not properly base64 encoded problem.
The error can appear for both service provider initiated and identity provider initiated sign-in. It does not mean your certificates are wrong or that the user account is blocked. It only says that the SAML message that arrived at Azure AD is not a valid Base64 string for the expected format.
Common Causes Of AADSTS750056 In Azure AD SAML Integrations
Before you start changing claims or certificates, it helps to group the usual root causes of AADSTS750056. Most real cases fall into a small set of encoding mistakes rather than deep protocol issues.
Plain XML Sent Instead Of Base64
Some custom integrations build the SAML AuthnRequest XML and send it directly on the query string without performing the DEFLATE and Base64 steps. Azure AD then reads the SAMLRequest parameter and expects a Base64 string, but instead receives characters like angle brackets and quotes, which cannot be decoded.
Double Encoding The SAML Message
Another common pattern is to encode the message correctly in the application code, then let a library or proxy apply a second Base64 or URL encoding pass. By the time the SAMLRequest reaches the Azure AD endpoint, the content no longer matches the expected compressed form, so decoding fails and the portal shows the AADSTS750056 error on the Microsoft sign-in page for users.
Wrong Binding Or Parameter Name
When the application uses HTTP Post instead of Redirect, or mixes SAMLRequest and SAMLResponse parameters at the wrong step, the contents may not line up with what the Microsoft endpoint expects. That mismatch can also surface with this same error because the handler cannot decode the bytes into a valid XML document.
Corrupted Message During Transport
Load balancers, web application firewalls, or test tools sometimes rewrite URLs and headers. If a proxy modifies plus signs, slashes, or padding characters in the Base64 string, the SAML payload will be corrupted. Performance test tools such as JMeter need special care so that the recorded DEFLATE plus Base64 value is sent back exactly as captured, without extra encoding passes.
| Cause | Typical Symptom | First Check |
|---|---|---|
| Plain XML instead of Base64 | SAMLRequest contains XML tags in browser tools | Inspect the SAMLRequest parameter value |
| Double encoding | Base64 decode gives another encoded string, not XML | Try decoding the value twice in a safe tool |
| Proxy rewriting | Plus signs or slashes replaced in the query string | Compare raw network trace with original value |
Reading the failing request this way lets you pick the right branch of the fix list quickly. If the SAMLRequest value is plain XML, you know the encode step never ran. If one decode gives another Base64 string, you know there is a second encode in the path. If certain characters change between the browser and a raw network trace, that points to a proxy or test tool that rewrites the query string.
Fixing AADSTS750056 SAML Base64 Encoding Errors In Azure AD
Once you know that the failure comes from a broken SAML message, you can walk through a set of direct checks on how the application builds and sends the request. For HTTP Redirect based flows, the rule is always the same sequence: DEFLATE, Base64 encode, then URL encode.
When you use HTTP Redirect binding, the presence of a long, mostly URL safe string in the address bar is a hint that the chain ran as expected. For HTTP Post flows, you should see the SAMLResponse value in a hidden form field rather than on the query string. If your scenario does not match these patterns, check whether custom code has swapped the binding type, or if a test harness rebuilt the message in a simpler but incorrect way.
- Capture A Fresh Failed Sign-In — Use the browser developer tools, SAML tracing extensions, or an HTTP proxy to record the exact redirect that carries SAMLRequest or SAMLResponse to the Azure AD endpoint.
- Copy The Raw SAML Parameter — Take the full value of the SAMLRequest or SAMLResponse parameter without trimming or editing characters, including plus signs and equals signs.
- Run A Single Base64 Decode — Paste the value into a trusted offline tool or language runtime and perform one Base64 decode. If the result is readable XML, Base64 encoding is likely fine and the issue may be earlier in the flow.
- Look For Binary DEFLATE Output — If the decoded bytes look like compressed data instead of XML, try running a DEFLATE decompression step. For Redirect binding this output should turn into clear SAML XML.
- Check For Double Encoded Strings — If the first decode gives another Base64 string rather than XML or binary, the message has probably been encoded twice. Adjust the code or middleware so that the chain runs only once per request.
- Review URL Encoding — Confirm that the Base64 string is URL encoded only once and that plus signs are not replaced with spaces by the time the request reaches Azure AD.
Libraries for SAML in languages such as .NET, Java, and Node usually handle this full chain if they are given the right binding type and endpoint URLs. The most common problems arrive when teams mix custom string handling with library defaults, or add custom reverse proxy rules that rewrite parameters after the SAML library has done its job.
How To Test And Validate Your SAML Response
To stop this Base64 encoding error in SAML sign-in flows from returning in the future, you need a repeatable way to test SAML requests and responses as you change settings. Lightweight tools make that much easier during both development and staging.
- Use A Browser SAML Trace Add-On — Tools that hook into the browser capture the redirects to the Microsoft login endpoint and show the decoded SAML contents side by side with the raw Base64 value.
- Keep A Known Good Sample — Once you reach a working setup, save a copy of a valid SAMLRequest and SAMLResponse pair. You can later compare new traffic against these samples to see where encoding changed.
- Validate With Official Docs — Cross check the binding, parameter names, and endpoint URLs with the current Microsoft Entra ID documentation so you are sure the payload matches the current rules.
- Test Through Every Proxy — Capture traces from behind load balancers, API gateways, and web application firewalls so you see whether any component rewrites characters in the Base64 payload.
- Automate A Simple Health Check — A small script that performs one SAML sign-in flow against a test tenant on a regular schedule can alert you when configuration changes reintroduce encoding errors.
When you treat SAML traffic like any other structured protocol and run these checks regularly, the Base64 encoding layer stops being a mystery and becomes just another step you can verify in a few seconds.
Working With Identity Provider Libraries And Middleware
Many cases of this Base64 encoding error in SAML flows come from mixing custom code with library defaults. Identity middleware often expects you to feed it plain XML and then let it handle compression and Base64 encoding. When developers compress or encode by hand before passing the message into the library, the output ends up malformed.
In .NET and Java based stacks, SAML libraries normally expose settings for HTTP Redirect or Post binding, entity IDs, and Azure AD metadata. Once those settings match what you see in the Microsoft Entra enterprise application configuration, the library will produce compliant requests. The safest approach is to let a single component own the encode and decode steps instead of spreading them across several helpers.
On platforms where you do not have a full SAML library, such as lightweight test tools or scripts, it helps to write a small helper that performs the DEFLATE and Base64 chain in one place. Then call that helper whenever you need to build SAMLRequest values, so the same logic applies for every redirect during your sign-in flow.
Preventing Future AADSTS750056 Errors In Production
Once you have corrected the immediate encoding bug, you can reduce the risk of it returning by baking a few habits into your deployment and change process. These steps cost little time and save long sign-in outages for users who depend on the SAML integration.
- Document The Encoding Steps — Write a short internal note that lists the exact sequence for SAMLRequest and SAMLResponse handling for your Azure AD apps and keep it close to the code.
- Lock Down Proxy Rewrites — Review rules on load balancers or web application firewalls that might rewrite query strings, so Base64 payloads pass through without rewriting plus or slash characters.
- Include SAML Tests In Release Pipelines — As part of your automated deployments, run a quick sign-in through the SAML app and assert that a valid session cookie arrives instead of an AADSTS750056 page.
- Monitor For Authentication Error Codes — Set up alerts or dashboards that surface spikes in this Base64 encoding issue in SAML user sign-ins so your team sees encoding problems shortly after they start.
- Stay Current With Microsoft Guidance — From time to time, review the latest Entra ID SAML documentation to check for binding changes or new endpoints introduced by the platform.
With these habits in place, your applications that rely on SAML stay more stable, and the specific Base64 encoding error in SAML user sign-in flows problem becomes something you rarely see outside a lab setup. When it does appear, you already have a clear plan to trace and fix it. That turns a confusing sign-in failure into a short checklist your team can work through with steady confidence.