Configure Auth0 as SAML Service Provider
These instructions explain how to configure Auth0 to serve as a service provider in a SAML federation. Auth0 only supports using Auth0 as the service provider in SAML configurations with SAML 1.1 or SAML 2.0.
When Auth0 serves as the SAML service provider, you need to use an Auth0 connection to configure the service provider side of each SAML federation. Next, you'll configure the IdP portion of your SAML setup. We have specific instructions for the following providers:
Use the following steps to configure Auth0 as a SAML service provider:
Obtain metadata and certificate from IdP.
Configure Auth0 as service provider.
Add service provider metadata to the identity provider.
Test the connection.
Obtain metadata and certificate from IDP
These instructions are generic. You will have to locate this information in your specific IdP.
SSO URL - The URL at the IdP to which SAML authentication requests should be sent. This is often called a SSO URL.
Logout URL - The URL at the IdP to which SAML logout requests should be sent. This is often called a logout URL, a global logout URL or single logout URL.
Signing certificate - The IdP will digitally sign authentication assertions and the signing certificate is needed by the service provider to validate the signature of the signed assertions. There should be a place to download the signing certificate from the IdP. If the certificate is not in .pem or .cer format, you should convert it to one of those formats.
Configure Auth0 as service provider
Click Create Connection.
Enter the following information:
Setting Description Connection Name Enter a connection name such as
Display Name If a value is provided, Universal Login will have the button say "Continue with (Display Name)". IdP Domains (Optional) Provide a comma-separated list of the domains that can be authenticated in the IdP. This step is only needed for identifier-first authentication flows If you leave this field blank, users with any email domain can use the IdP. Sign In URL Enter the SAML SSO URL that you obtained from the IdP. Sign Out URL Enter the SAML Logout URL obtained from the IdP. Certificate Click on the red "UPLOAD CERTIFICATE" button and select the
.pemfile you obtained from the IdP.
User ID Attribute The attribute in the SAML token that will be mapped to the
user_idproperty in Auth0. If not set, then the
user_idwill be retrieved from the following (in listed order):
Click Continue. In the window that appears, metadata about this SAML service provider is displayed. You will need to use the information from this screen to configure the IdP.
The first bullet is the post-back URL or Assertion Consumer Service (ACS) URL. This is the URL the Identity Provider will send Authentication Assertions to after authenticating a user. Enter this value where the IdP asks for Assertion Consumer Service URL. It may just call this a Service Provider URL.
The second bullet tells you the Entity ID. It will be of the form urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME. Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. Use this value if the Identity Provider asks for Entity ID or SAML Audience.
The third bullet indicates the binding that will be used to send the SAML Request from Auth0 to the Identity Provider. If the Identity Provider provides a choice, select HTTP-Redirect as shown on your metadata screen.
The fourth bullet indicates that Auth0 expects the Identity Provider to respond with an HTTP POST, such as the Authentication Assertion from the Identity Provider will be sent using the HTTP POST binding. If the Identity Provider provides a choice, indicate that HTTP-POST binding should be used for Authentication Assertions. The nameid format is the format for the attribute that will be used to identify users.
In that same window, near the bottom, there is a line that says, "You can access the metadata for your connection in Auth0 here:". In general, you can access the metadata for a SAML connection in Auth0 here:
Make a note of this metadata URL as you may be able to use it to configure the IdP in the next section.
Add service provider metadata to IdP
In this section you will add some information to the IdP so it knows how to receive and respond to SAML-based authentication requests from the Auth0 service provider. The instructions provided here are generic. You will need to find the appropriate screens and fields on the Identity Provider.
Locate the screens in the Identity Provider that allow you to configure SAML. If the IdP supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above. If the IdPr does not support uploading a metadata file, you can configure it manually as follows.
The IdP will need to know where to send the SAML assertions after it has authenticated a user. This is the Assertion Consumer Service URL in Auth0. The IdP may call this Assertion Consumer Service URL or Application Callback URL.
connectionURL parameter is required for identity provider-initiated flows. Note that if you have custom domains set up, you should use the custom domain based URL rather than your Auth0 domain. So, it should be in the format of
If the IdP has a field called Audience or Entity ID, rnter into that field the Entity ID from Auth0:
If the IdP provides a choice for bindings, you should select HTTP-Redirect for Authentication Requests.
The Single Logout Service URL, where SAML logout requests and/or responses from the Identity Provider must be sent, should be configured as:
Signing Logout Requests: When configuring the IdP, make sure that SAML Logout Requests sent to the service provider are signed.
In the Dashboard, navigate to: Connections > Enterprise > SAMLP Identity Provider.
Click on the triangular Try button for the SAML connection you created earlier. This button is to the right of the name of the connection. You can hover your mouse over the button to have the text label appear.
You will first see a Lock login widget appear that is triggered by the Service Provider. Enter the username. If you entered an email domain in the SAMLP connection configuration, the username should belong to that email domain.
You will then be redirected to the login screen of the Identity Provider. Login with the credentials for a user that exists in the Identity Provider.
If the SAML configuration works, your browser will be redirected back to an Auth0 page that says It works. This page will display the contents of the SAML authentication assertion sent by the Identity Provider to Auth0 Service Provider. This means the SAML connection from Auth0 Service Provider to Identity Provider is working.
If it didn't work, double check the above steps and then consult the troubleshooting section at the end of this document.
If your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your HTML page or it may have stale cookies that impact execution.
When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis. Search for "HTTP Trace" to find some. Once you have an HTTP trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application.
Check to make sure that the callback URL specified by your application in its authentication request is listed in the Allowed Callback URLs field.
To do so, go to Dashboard, click on Applications, then on the Settings icon to the right of the application name.
The http://samltool.io tool can decode a SAML assertion and is a useful debugging tool.
Supported algorithms for signatures
We currently support the following algorithms for processing XML Digital Signatures: