Common Entra ID SAML errors and how to fix them

Setting up SAML SSO with Microsoft Entra ID is rarely a one-shot success. Between the Entra admin center, your app's configuration, and the IT admin on the other side who set it all up, there are at least a dozen places things can silently go wrong. The result is usually the same: a login page that never progresses, a vague error code, and a support ticket that bounces between your team and your customer's IT department.

This post covers the most common Entra ID SAML errors developers and IT admins run into (the real ones, with real error codes) and exactly what to do about each of them.

Debugging tools for Entra ID

Microsoft provides a browser extension called the My Apps Secure Sign-in Extension (available for Chrome and Edge) that captures SAML requests and responses automatically and surfaces resolution guidance in the Entra portal. It's worth installing before you start poking around. Alternatively, SAML Tracer (Firefox/Chrome) lets you inspect the raw XML flowing between your app and Entra ID in real time, which is useful for seeing exactly what attributes are (and aren't) being sent.

To test a SAML connection from the Entra side: go to Entra ID > Enterprise applications > [Your app] > Single sign-on, scroll to step 5, and click Test. This lets you sign in as yourself or another user and will show you the error inline.

Error 1: AADSTS50011 - Reply URL mismatch

What you see:

AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application <GUID>. Make sure the reply URL sent in the request matches one added to your application in the Azure portal.

What's happening:

The AssertionConsumerService URL (ACS URL) that your application is sending in its SAML AuthnRequest doesn't match any of the reply URLs registered in Entra ID for that application. Entra ID won't post the SAML response to a URL it doesn't recognize.

This is the most common SAML error with Entra ID and shows up in a surprising number of situations: after upgrades or migrations that change the app's base URL, when deploying to a new environment (staging vs. production), when there's an HTTP/HTTPS mismatch, or when a trailing slash is present on one side and not the other. Entra ID's matching is exact: case, scheme, path, and trailing slash all matter.

How to fix it:

1. Capture the SAML request (use the My Apps extension or SAML Tracer) and note the AssertionConsumerServiceURL value.
2. In Entra ID, go to Enterprise applications > [Your app] > Single sign-on > Basic SAML configuration.
3. Add the exact URL from the request to the Reply URL (Assertion Consumer Service URL) field.
4. Save and test.

If your app sits behind a reverse proxy (nginx, an API gateway, a Kubernetes ingress), the URL your app sends may differ from what the proxy exposes externally. Make sure the ACS URL your SAML library uses reflects the external address your customers will actually hit, not localhost or an internal hostname.

Error 2: AADSTS50105 - User not assigned to the application

What you see:

AADSTS50105: The signed in user is not assigned to a role for the application. Your administrator has configured the application <AppName> to block users unless they are specifically granted access.

What's happening:

The Entra enterprise application has Assignment required set to Yes, which means Entra ID will only issue a SAML assertion for users (or members of groups) explicitly assigned to that application. The user trying to sign in hasn't been assigned.

This catches a lot of people off guard during initial setup: you've configured everything correctly, but you forgot to assign yourself (or any user) to the app before testing.

There's also a nested-groups gotcha here. If you've assigned a group to the application and the user is a member of a child group of that group, they'll still get this error. Entra ID requires users to be direct members of an assigned group, not members via nesting.

How to fix it:

To assign individual users or groups:

1. In Entra ID, go to Enterprise applications > [Your app] > Users and groups.
2. Click Add user/group.
3. Select the users or groups you want to grant access, pick a role (or use Default Access), and click Assign.

To allow all users in the tenant to access the app with no assignment required:

1. Go to Enterprise applications > [Your app] > Properties.
2. Set Assignment required to No.
3. Save.

If nested groups are the issue, the workaround is to assign the parent group directly or flatten your group structure for this application. Entra ID's SAML flow does not expand nested group membership.

Error 3: AADSTS75005 - Invalid SAML request

What you see:

AADSTS75005: The request is not a valid Saml2 protocol message.

What's happening:

Entra ID received a SAML AuthnRequest from your application that it can't parse or doesn't support. This typically means the request is missing required fields, the XML is malformed, or the request is being sent with an encoding or format Entra ID doesn't recognize.

Common causes:

• The SAML library is generating a request that doesn't include required elements (like ID, IssueInstant, or Issuer)
• The request is double-encoded or encoded incorrectly (e.g., Base64 where URL-encoding is expected or vice versa)
• The SAML version specified in the request is SAML 1.1 instead of 2.0

How to fix it:

Capture the raw SAML request using the My Apps extension or Fiddler and decode it (it will be Base64 + URL-encoded in a redirect binding). Check:

• Version attribute is 2.0
• ID attribute is present and unique
• IssueInstant is present and correctly formatted (ISO 8601 UTC)
• Issuer matches the entity ID configured in Entra ID

If this is happening with a SAML library, check whether the library has known issues with the Entra ID SAML implementation and update to the latest version. Contact the application vendor and share the decoded SAML request. Microsoft's guidance for this error is to have the vendor validate their implementation against Entra ID's SAML profile.

Error 4: AADSTS750054 - Wrong binding type

What you see:

AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding.

What's happening:

Your application sent a SAML request using HTTP POST binding, but the SSO URL you configured in your app is set up for HTTP Redirect binding (or vice versa). Entra ID expected to find the SAMLRequest as a query string parameter in the URL but couldn't find it there.

HTTP Redirect binding sends the SAML request URL-encoded in the query string (?SAMLRequest=...). HTTP POST binding sends it in the body of a form POST. If the binding your app uses doesn't match what Entra ID's SSO endpoint expects at that URL, the request fails immediately.

How to fix it:

Check the SSO URL you've configured in your app. In Entra ID's SAML-based sign-on configuration, you'll find two URLs under Set up [AppName]:

• Login URL for HTTP Redirect binding
• Microsoft Entra ID identifier (the SAML SSO endpoint), configurable per binding

Ensure the SSO endpoint URL your application is pointing to matches the binding your SAML library uses. If you're using HTTP POST binding, verify your library is sending the request in the form body and that the Entra SSO endpoint you're targeting accepts POST.

Error 5: Expired SAML signing certificate

What you see:

Users are suddenly unable to log in. The error varies: your app may show a generic "authentication failed" message or a signature validation error. The Entra sign-in logs may show AADSTS50002 (token signing key not found) or your app's SAML library will throw a signature verification failure.

What's happening:

By default, Entra ID generates SAML signing certificates that expire after three years. When the certificate expires, Entra ID continues to sign assertions with it, but your application rejects them because the certificate is no longer valid. Entra ID sends email notifications at 60, 30, and 7 days before expiration to the addresses configured on the enterprise application. If no one is watching those emails, the first sign anything is wrong is users being locked out.

The rotation process has a coordination problem: you need to generate the new certificate in Entra ID before activating it, update your application with the new certificate, and then activate it in Entra ID, in that order. Doing it out of sequence causes a window where SSO is broken.

How to fix it:

The rotation sequence (do this in order):

1. In Entra ID, go to Enterprise applications > [Your app] > Single sign-on > SAML Signing Certificate.
2. Click New Certificate. Don't activate it yet. Download the new certificate (Base64 format).
3. Update your application or WorkOS configuration with the new certificate. At this point, both the old (active) and new (inactive) certificates exist in Entra ID.
4. Test that the old SSO flow still works (it should, since the old cert is still active).
5. Back in Entra ID, click the ellipsis on the new certificate and select Make certificate active.
6. Test SSO immediately. If something is wrong, you can reactivate the old certificate.

To get ahead of future expirations, add multiple email addresses to the notification list in the SAML Signing Certificate section, including your on-call alias and not just the admin who set up the integration. As an ISV, consider polling Entra's federation metadata endpoint to detect when a new certificate has been added, so you can pre-load it before it's activated and handle rotation automatically.

Error 6: NameID format mismatch

What you see:

Users can authenticate with Entra ID but your application fails to recognize them afterward, often with a "user not found" error on the application side. In the SAML assertion, the NameID is present, but in an unexpected format.

What's happening:

The NameID in the SAML assertion is the primary identifier your app uses to look up or provision the user. Entra ID can send it in several formats: email address (user@domain.com), the user's UPN, an opaque persistent identifier, or a transient identifier. If your app expects an email address but receives an opaque GUID, it won't find or create the user correctly.

The specific format Entra ID sends depends on what's configured in the User attributes & claims section of your app's SSO configuration. By default, Entra ID uses the user's UPN for the NameID, which usually looks like an email address but is technically distinct. For users in federated tenants, the UPN may not match the user's actual email.

How to fix it:

1. In Entra ID, go to Enterprise applications > [Your app] > Single sign-on > Attributes & Claims.
2. Click the pencil icon next to Unique User Identifier (Name ID).
3. Check the Source attribute. If your app expects email, change this to user.mail. If your app expects UPN, use user.userprincipalname.
4. Check the Name identifier format dropdown and ensure it matches what your app expects (Email address, Persistent, Transient, etc.).

Use SAML Tracer to see exactly what's being sent in the NameID element today and compare it to what your application expects. If your app creates new user records on first login (just-in-time provisioning), an unexpected NameID format can result in duplicate users being created under each format, which is painful to clean up.

Error 7: AADSTS700016 - Application not found in directory

What you see:

AADSTS700016: Application with identifier (Client ID) <identifier> was not found in the directory <directory name>.

What's happening:

The entity ID (also called SP identifier or issuer) in your SAML request doesn't match any application registered in the Entra ID tenant you're authenticating against. Entra ID uses the entity ID to look up the enterprise application; if it can't find a match, authentication fails before it even starts.

This commonly happens when:

• Your customer configured the entity ID differently in Entra ID than what your app sends
• Your app is pointing at the wrong Entra tenant (wrong tenant ID in the SSO URL)
• The entity ID has a trailing slash, case difference, or scheme mismatch compared to what's registered
• The enterprise application was deleted and recreated, changing its registered identifiers

How to fix it:

1. Check the entity ID your application is sending (capture the SAML request, decode it, and find the <Issuer> element).
2. In Entra ID, go to Enterprise applications > [Your app] > Single sign-on > Basic SAML configuration.
3. Verify the Identifier (Entity ID) field exactly matches the issuer in your SAML request, character for character.
4. If the tenant is wrong, verify the SSO URL your app uses contains the correct tenant ID.

How WorkOS helps with Entra ID SAML errors

Several of the errors above are ones WorkOS handles for you or makes significantly easier to manage.

• For configuration mismatches (reply URL, entity ID, NameID format), the Admin Portal guides your customers' IT admins through setup and pre-populates the values your app requires, removing the main source of copy-paste errors.
• For certificate expiration, WorkOS monitors all your connections and surfaces upcoming expirations in the dashboard at 90 days out, sends email and Slack alerts to your team, can email the IT admin directly with a self-serve renewal link, and supports metadata URLs so Entra's certificate is automatically pulled in when it rotates. For more on this, see Managing SAML X.509 Certificates.
• For errors rooted in how SAML requests are constructed (invalid request format, wrong binding type), those don't apply when you're using WorkOS, since WorkOS generates and validates the SAML exchange on your behalf.

Get started with WorkOS and Entra ID SAML here.