Troubleshoot Auth0 SAML Configurations

Jun 2, 2026

Overview

Auth0 Security Assertion Markup Language (SAML) configurations support multiple roles and authentication flow models, each of which introduces distinct failure points. When SAML authentication fails, the troubleshooting areas covered include identifying Auth0's role in the flow, checking affected users, resolving common errors when Auth0 acts as the Service Provider (SP), and diagnosing login stage failures when Auth0 acts as the Identity Provider (IdP).

Applies To

Auth0
Security Assertion Markup Language (SAML)
Single Sign-On (SSO)
Identity Provider (IdP)
Service Provider (SP)
Software as a Service (SaaS)
Enterprise Connections
SP-Initiated and IdP-Initiated Authentication Flows

Solution

Understanding the Auth0 SAML Configuration

Before troubleshooting, gather answers to the following questions to understand the configuration:

Is Auth0 serving as the SAML SP, the SAML IdP, or both?
- The SP redirects users to another service for authentication. The IdP authenticates the user by prompting them to sign in and validating the information provided. If the application redirects the user to Auth0 for SAML authentication, Auth0 is the IdP. If Auth0 redirects users via a Connection to a remote IdP via SAML, Auth0 is the SP to the remote IdP. Auth0 can act as the SP, IdP, or both.
Does the authentication flow use an SP-initiated model, an IdP-initiated model, or both?
- SP-initiated authentication flows begin when the user navigates to the SP application and is redirected to the IdP for sign-in. An IdP-initiated flow means the user navigates to the IdP, signs in, and then gets redirected to the SP application. Within enterprise settings, the IdP-initiated flow is most common.
Which user profile attribute identifies the user at the IdP during sign-in and within each application?
- If the naming attribute differs between the IdP and the application(s), configure the appropriate mappings within Auth0 so that Auth0 sends the correct user profile attributes to the application(s).
  - Using the email address as the unique identifier is the simplest option, though privacy concerns apply.
  - Enterprise organizations often use an internal ID with the IdP, which requires mapping to another attribute meaningful to outsourced Software as a Service (SaaS) applications.
Are authentication requests signed?
Are authentication assertions encrypted?

Gather information that helps answer the following questions before beginning to troubleshoot:

How many users experience the issue, just one user, or all users?
Is the issue with a new setup, or is it an existing integration that stopped working?
How many applications does the issue affect?
What is the expected behavior, and what is the observed behavior?
How far through the sign-in sequence does the user get?

How to Check Affected Users

Review the user's profile, browser, or device for issues by checking the following:

Confirm whether the issue occurs in all browsers for the affected users, indicating a data issue, or only in certain browsers, indicating a browser-specific issue.
Confirm that the browser has JavaScript and cookies enabled.
Confirm that the Caps Lock key is disabled.
If the user is using a mobile device, confirm that no software is installed that might impact authentication and/or authorization.
Confirm that the user can access key URLs, such as the IdP's SSO URL, to rule out network connectivity issues.

How to Troubleshoot Auth0 as a Service Provider

Common Errors When Auth0 Acts as the Service Provider

The following sections describe common errors that occur when Auth0 acts as the SP and the steps to resolve them.

How is the connection was disabled error resolved in Auth0?

The following error indicates that the application does not have an active Connection associated with it:

"error": "invalid_request", "error_description": "the connection was disabled"

Navigate to the Auth0 Dashboard > Authentication > Enterprise, select a connection type, open the connection settings, and enable at least one application on the Applications view.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select a connection type.
Select the name of the Connection.
Select the Applications view.
Enable at least one application. If no applications appear in the list, create an application before proceeding.

How is the IdP-Initiated login is not enabled for connection error resolved in Auth0?

The following error typically occurs because the Assertion Consumer Service (ACS) URL configured in the IdP used the default Auth0 tenant domain, while the authentication transaction was started by calling the Custom Domain /authorize endpoint:

"invalid_request": "IdP-Initiated login is not enabled for connection 'CONNECTION_NAME'."

If this error appears during an SP-initiated flow, one of the following is missing or empty:

RelayState parameter.
InResponseTo attribute in the SAML response

If these are missing or empty, Auth0 treats the sign-in as IdP-initiated. Check the configuration to ensure that both fields are populated and returned appropriately.

Navigate to the Auth0 Dashboard > Authentication > Enterprise, select the connection, open the IdP-Initiated SSO view, and configure the IdP-Initiated SSO Behavior and Default Application settings.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select a connection type.
Select the name of the Connection.
Select the IdP-Initiated SSO view.
Locate IdP-Initiated SSO Behavior, and select Accept Requests to enable IdP-initiated sign-ins.
Select the Default Application and the Response Protocol used by that application, and optionally specify any additional parameters to pass to the application.

How is the InResponseTo attribute does not match the ID in AuthNRequest resolved in Auth0?

InResponseTo attribute does not match the ID in AuthNRequest

This error occurs when the InResponseTo attribute in the SAML response is not recognized by the Auth0 tenant. Possible causes include:

Blocked cookies.
Mismatched IDs from the most recent SAML request.
Inconsistent use of domains.

If the tenant uses a custom domain, a mismatch can occur if the sign-in flow begins on the custom domain and finishes on the canonical domain. For example, the user starts at the custom domain:

https://auth.{exampleDomain}.com/authorize?client_id=abc123&redirect_uri=https://jwt.io&response_type=code&scope=openid&audience=https://example.com&connection=mysamlconnection

But the IdP is configured to return the SAML response to the ACS URL at the canonical domain:

https://{exampleTenant}.auth0.com/login/callback

If the ID is returned to another domain in the InResponseTo attribute of a SAML response, Auth0 does not have a record of it and returns the above error. Use the same domain throughout the sign-in flow.

Change either the domain in the initial /authorize request or the ACS URL configured with the IdP.

How is the Default App for IdP-Initiated is not configured error resolved in Auth0?

The following error typically occurs when IdP-initiated flows are enabled, but the necessary information to execute the flow has not been provided:

"invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter."

The ACS URL must use the same domain as the initial authentication request. If using custom domains, use the custom domain callback URL.

If this error appears during an SP-initiated flow, one of the following is missing or empty:

RelayState parameter.
InResponseTo attribute in the SAML response.

If these are missing or empty, Auth0 treats the sign-in as initiated by the IdP. Check the configuration to ensure that both fields are populated and returned appropriately.

Navigate to the Auth0 Dashboard > Authentication > Enterprise, select the connection, open the IdP-Initiated SSO view, and configure the Default Application and Response Protocol settings.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select a connection type.
Select the name of the Connection.
Select the IdP-Initiated SSO view.
Select the Default Application and the Response Protocol used by that application, and optionally specify any additional parameters to pass to the application.

What Causes the Missing RelayState Error?

Missing RelayState

This error occurs when the IdP does not return the RelayState parameter along with its response. Work with the IdP to ensure that it returns the RelayState parameter.

What Causes the Audience Invalid Error?

Audience invalid

This error occurs when the value of the audience element from the IdP's SAML response does not match the value Auth0 expects. Auth0 expects the value to be the Connection's Entity ID.

Navigate to the Auth0 Dashboard > Authentication > Enterprise, select the connection, open the Setup view, and locate the Entity ID in the Common Settings section. Then confirm that the IdP sends the correct audience value in the SAML response.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select a connection type.
Select the name of the Connection.
Select the Setup view, and locate the Common Settings section. The Entity ID is the second parameter listed.
Confirm that the IdP sends the correct audience value in the SAML response.

An Incorrect Response Protocol Causes Errors on the IdP-Initiated Tab

One common error is specifying the incorrect response protocol on the IdP-Initiated tab. The response protocol is the one used between Auth0 and the application, not the remote IdP. For example, setting this value to SAML when the application expects OpenID Connect or WS-Fed results in errors.

Navigate to the Auth0 Dashboard > Authentication > Enterprise, select the connection, and verify the Response Protocol value on the IdP-Initiated SSO view.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select a connection type.
Select the name of the Connection.
Select the IdP-Initiated SSO view, locate Response Protocol, and verify its value.

The User Is Not Signed Out of the IdP When the Name ID Attribute Is Not Mapped

When Active Directory Federation Services (ADFS) is configured as the SAML IdP, if the ADFS relying party trust Name ID attribute is not mapped, the sign-out flow fails. For example, with the federated parameter v2/logout?federated&..., the user is not redirected to the ADFS SAML sign-out endpoint and is instead redirected back to the application callback URL directly. As a result, the user is not signed out of the IdP.

Add the Name ID attribute as a rule on the SAML Relying Party Trust.

SAML Sign-In Issues Have Four Primary Stages to Check

When troubleshooting a SAML sign-in, check the following four stages:

Stage 1: The user is successfully redirected to an IdP and can sign in.
Stage 2: After signing in with the IdP, the user returns to Auth0 with a successful sign-in event recorded.
Stage 3: After a successful sign-in event in Auth0, the user profile in Auth0 is correct.
Stage 4: The user successfully redirects to the application and can access it.

The IdP Sign-In Page Does Not Display

Navigate to Auth0 Dashboard > Authentication > Enterprise, select the SAML connection, use the Try icon to test the connection, and then review the connection settings with the IdP administrator if the test fails.

Navigate to Auth0 Dashboard > Authentication > Enterprise, and select SAML.
Locate the connection, and select its Try (triangle/play) icon to test the interaction between Auth0 and the remote IdP. If the Connection does not work, continue with the steps in this section. If it does work, proceed to the next section.
Next to the SAML connection, select Settings (represented by the gear icon).

Dashboard Authentication Enterprise SAML Connection Settings

Check and confirm the following with the IdP administrator:
1. The Sign In URL is the correct SSO URL. This is the URL that Auth0 redirects the user to for authentication.
2. Whether the IdP expects HTTP-POST binding or HTTP-Redirect binding. Switch the default binding on the Settings tab.
3. Whether authentication requests should be signed, and if so, which signing algorithm the IdP expects.
  - NOTE: Authentication requests are not commonly signed. If sending signed requests, enable the Sign Request toggle in the Connection Settings and confirm that the Signing Algorithm value matches what the IdP expects.
4. Ask the IdP administrator to check for log entries that might provide information about the issue.

Auth0 Logs Do Not Show a Successful Sign-In Event

In this case, the user successfully signs in with the IdP, but Auth0 logs do not show a successful sign-in event.

Check the Auth0 logs and user records, capture an HTTP trace of the sign-in sequence, analyze the trace in a HyperText Markup Language Archive (HAR) file analyzer, and decode the SAML response in a SAML debugger to identify assertion issues.

Check the Logs and Users pages in the Auth0 Dashboard to see if Auth0 shows a successful sign-in event. If Auth0 logs do not show a successful sign-in event, there is likely an issue with the SAML Authentication Assertion returned by the IdP, or Auth0 is unable to consume the assertion.
Check the information that Auth0 sends to the application by capturing an HTTP trace of the sign-in sequence and analyzing the HTTP trace.
View the HTTP trace in a HAR file analyzer. For example, Google's HAR Analyzer is one option; use a tool that best fits the organization's guidelines.
1. Scan through the sequence of URLs invoked in the HTTP trace.
  1. The first few will be URLs for the application.
  2. There will then be a redirect to an Auth0 URL (such as {exampleDomain}).
2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the ACS of Auth0, which consumes the assertion and extracts the needed information.
3. Select the row for the POST call in the HAR analyzer.
4. Switch to the POST Data tab, and look for the SAML response.
5. Copy and paste the SAML response into a SAML debugger.
6. Remove the "SAML response" at the beginning, as well as anything beginning with &RelayState= at the end.
After retrieving and decoding the SAML message, check the following fields:
- Field
- Description

User Profile Attributes Are Incorrect After a Successful Sign-In Event

In this case, the user successfully signs in with the IdP, and Auth0 logs show a successful sign-in event, but the user's profile attributes are not correct.

Check the user's Auth0 profile, enable Debug Mode on the SAML connection to inspect the assertion, and configure attribute mappings on the Mappings tab if values are present but mapped incorrectly.

Go to Dashboard > User Management > Users.
Find and select the specific user to open their profile. If there are multiple rows for a given user, open the record associated with the SAML Connection.
View the user's details using the Details tab or the Raw JSON tab. This shows what attributes Auth0 has received from the IdP.
If an attribute is missing, check whether it was included in the assertion by decoding the SAML assertion or by enabling Debug Mode for the connection.
1. To enable Debug Mode, navigate to Authentication > Enterprise.
2. Open the list of SAML IdP connections, select Settings, and enable Debug Mode.

Troubleshoot SAML Connections Enable Debug Mode screen

1. With Debug Mode enabled, Warning During Login log entries in the Dashboard include an original_profile property that lists every attribute included in the SAML assertion by the IdP. Use this list to see the information the IdP is sending and to help create the mappings. If the missing attribute is not in the assertion, work with the IdP to ensure it is included.
If an attribute value exists in the Auth0 user profile but is not mapped to the correct attribute, correct this using the Connection Mapping capability.
1. Navigate to Authentication > Enterprise.
2. Open the list of SAML IdP connections and go to the Mappings tab.

Troubleshoot SAML Connections Enable Debug Mode screen

1. Within the provided editor, a JSON snippet is available to configure mappings. The name on the left is the Auth0 user profile attribute to which the assertion value will be mapped. The value on the right is the identifier in the SAML assertion from which the attribute comes. When Auth0 incorporates unmapped SAML attributes into the user profile, attribute identifiers containing dots (.) are replaced with semicolons (:). Ensure the identifiers provided match those in the SAML assertion.

The User Cannot Access the Application After Auth0 Shows Successful Sign-In Event

In this case, the user successfully signs in with the IdP, Auth0 logs show a successful sign-in event, and the user's profile attributes are correct, but the user cannot access the application.

Check the application's log files, capture and analyze an HTTP trace of the sign-in sequence using a HAR file analyzer, decode the SAML assertion to verify its contents, and review the IdP-initiated flow configuration and any rules or multi-factor authentication settings that may be interfering.

Check the application's log files for error messages indicating why the user is unable to access the application. The two most common causes are:
- Missing user profile information.
- Incorrect or missing authorization information.
Check the information Auth0 sends to the application by capturing an HTTP trace of the sign-in sequence and analyzing it. View the HTTP trace in a HAR file analyzer. For example, Google's HAR Analyzer is one option; use a tool that best fits the organization's guidelines.
1. Scan through the sequence of URLs invoked in the HTTP trace.
  1. The first few will be URLs for the application.
  2. There will then be a redirect to an Auth0 URL (such as {exampleDomain}).
2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the ACS of Auth0, which consumes the assertion and extracts the needed information.
3. Select the row for the POST call in the HAR analyzer.
4. Switch to the POST Data tab, and look for the SAML response.
5. Copy and paste the SAML response into a SAML debugger.
6. Remove the SAML response at the beginning, as well as anything beginning with &RelayState= at the end.
After retrieving and decoding the SAML message, check the following fields:
- Field
- Description

If the authorization flow uses an OpenID Connect (OIDC)-conformant protocol, capture a HAR trace and view it using a HAR file analyzer. For example, Google's HAR Analyzer is one option; use a tool that best fits the organization's guidelines.
1. Scan through the sequence of URLs in the trace and look for the following:
  1. The first few will be URLs for the application.
  2. There will then be a redirect to an Auth0 URL (such as {exampleDomain}).
2. Further down is the application's callback URL. Confirm that it is correct.
3. Retrieve the ID Token from this call, and paste it into a JSON Web Token (JWT) decoder. Check that the claims in the token include the information the application needs.
If using an IdP-initiated flow (for example, the user starts at the IdP in a portal application), confirm the following:
1. The ACS URL at the IdP includes the connection name (for example, https://{exampleDomain}/login/callback?connection=CONNECTION_NAME).
2. The IdP-initiated configuration tab for the Connection is properly filled in, including:
  - The IdP-initiated SSO behavior is set to Accept Requests.
  - The application to which the user should be sent.
  - The protocol between the application and Auth0, which is not necessarily SAML and is most likely OpenID Connect.
  - Any protocol-specific values to include in the query string, such as scope, response_type, redirect_uri, and audience. These values must match the ones expected by the application when using an SP-initiated flow.
3. Temporarily disable rules to confirm that nothing is interfering with the sign-in process.
4. If Multi-Factor Authentication (MFA) is enabled, temporarily disable it to confirm that it is not interfering with the sign-in process.
5. Check that the SAML Connection works in an SP-initiated flow by using Try to run a Connection test.

What Causes the SAML Responder or SAML Authority Error?

The error may appear as follows:

<samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /> </samlp:Status>

Confirm that the signature algorithm on the Auth0 connection matches the configuration on the ADFS side — either rsa-sha256 or rsa-sha1. Alternatively, contact the ADFS administrator to confirm the expected signing method or to check whether their logs contain further information about the error.

How to Troubleshoot Auth0 as an Identity Provider

When troubleshooting a SAML sign-in with Auth0 acting as the IdP, check the following four stages:

Stage 1: The user is successfully redirected to the IdP and can sign in.
Stage 2: After signing in with the IdP, the user returns to Auth0 with a successful sign-in event recorded.
Stage 3: After a successful sign-in event in Auth0, the user profile in Auth0 is correct.
Stage 4: The user successfully redirects to the application and can access it.

A Successful Sign-In Event Does Not Appear in Auth0 Logs

In this case, the user successfully signs in with the IdP, but a successful sign-in event does not appear in Auth0 logs.

If using an Auth0 Database Connection:
1. Confirm that the user exists and that the entered password is correct.
2. Temporarily disable rules to confirm that nothing is interfering with the sign-in process.
3. If MFA is enabled, temporarily disable it to confirm that it is not interfering with the sign-in process.
If using an Auth0 Database Connection or a remote SAML connection, confirm that the SAML Connection works by using Try to run a Connection test.

User Profile Attributes Are Incorrect When Auth0 Acts as the Identity Provider

In this case, the user successfully signs in with the IdP, a successful sign-in event appears in Auth0 logs, but the user's profile attributes are incorrect.

If the user appears to sign in successfully, the Logs and Users pages in the Auth0 Dashboard should show successful sign-in events. Check that the user's profile contains the necessary user profile attributes.

Navigate to the Dashboard > User Management > Users, open the specific user's profile, and review the Details or Raw JSON tab to confirm what attributes Auth0 has received from the IdP.

Go to Dashboard > User Management > Users.
Find and select the specific user to open their profile. If there are multiple rows for a given user, open the record associated with the SAML Connection.
View the user's details using the Details tab or the Raw JSON tab. This shows what attributes Auth0 has received from the IdP. If an attribute is missing, check with the IdP to confirm that it has the attribute and that it is returning that attribute to Auth0.

The User Cannot Access the Application When Auth0 Acts as the Identity Provider

In this case, the user successfully signs in with the IdP, a successful sign-in event appears in Auth0 logs, and the user's profile attributes are correct, but the user cannot access the application.

Check the user's Auth0 profile for completeness, review the application's log files for errors, capture and analyze an HTTP trace using a HAR file analyzer, decode the SAML assertion to verify its contents, and use rules to add or map any missing attributes in the assertion sent from Auth0 to the application.

Check that the user's Auth0 profile is populated correctly:
1. Go to Dashboard > User Management > Users.
2. Find and select the specific user to open their profile. If there are multiple rows for a given user, open the record associated with the SAML Connection.
3. View the user's details using the Details tab or the Raw JSON tab. Confirm that the profile includes all required application details. If a user attribute is missing, check with the IdP to confirm that it has the attribute and that it is returning that attribute to Auth0.
Check the application's log files for error messages indicating why the user is unable to access the application. The two most common causes are missing user profile information and incorrect or missing authorization information.
Check the information Auth0 sends to the application by capturing an HTTP trace of the sign-in sequence and analyzing it. View the HTTP trace in a HAR file analyzer. For example, Google's HAR Analyzer is one option; use a tool that best fits the organization's guidelines.
1. Scan through the sequence of URLs invoked in the HTTP trace.
  1. The first few will be URLs for the application.
  2. There will then be a redirect to an Auth0 URL (such as {exampleDomain}).
2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the ACS of Auth0, which consumes the assertion and extracts the needed information.
3. Select the row for the POST call in the HAR analyzer.
4. Switch to the POST Data tab, and look for the SAML response.
5. Copy and paste the SAML response into a SAML debugger.
6. Remove the SAML response at the beginning, as well as anything beginning with &RelayState= at the end.
After retrieving and decoding the SAML message, check the following fields:
- Field
- Description

Confirm that the SAML assertion contains any additional information required by the application and that the information is present in the attributes expected by the application.
- To modify the assertion sent from Auth0 to the application, add or map attributes using rules.
  1. Sign in to Auth0 and navigate to Rules.
  2. Select Create Rule and, on the next page, choose the Change your SAML configuration template.
  3. In the rules editor, uncomment the lines to use. Use lines 9–17 in the template to map attributes as needed. Add lines to implement additional mappings. The left side of each line specifies the identifier for the attribute in the assertion. The right side references the Auth0 user profile attribute whose value will populate the outgoing assertion sent to the application.
```
//context.samlConfiguration.mappings = {    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":      "user_id",    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":        "email",    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":                "name",    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname":           "given_name",    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname":             "family_name",    
    // "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":                 "upn",    
    // "http://schemas.xmlsoap.org/claims/Group":                                   "groups"    
    // };
```

How is the No active session(s) found matching LogoutRequest error resolved in Auth0?

No active session(s) found matching LogoutRequest

The SessionIndex and NameID values in the SAML Logout request must match the ones received by the SP in the original SAML assertion.

Confirm that both values align between the logout request and the original assertion.

Contact Auth0 Support

If the troubleshooting steps above do not resolve the issue, open a ticket in the Auth0 Support Center. Include the following information:

The number of users experiencing the issue — one or all?
Whether the issue involves a new setup or an existing integration that stopped working.
The number of applications affected.
The expected and current behaviors.
How far through the sign-in sequence the user gets.
The name of the application registered in Auth0 and the identity protocol it uses.
The name of the Connection involved.
Whether the Auth0 Lock widget is in use, and if so, which version.
Whether a customized version of Lock is in use.
An HTTP trace of the SSO interaction in a HAR file.
An Auth0 log entry for the failed authentication.
An authentication log file from any third-party applications involved, such as SharePoint.