Articles

Connect Auth0 to Okta for Enterprise SSO (2026)

April 16, 2026 5 min read

Auth0 and Okta are both identity providers, and connecting them for enterprise SSO means you’re setting up one to act as a "Service Provider" (SP) and the other as an "Identity Provider" (IdP). This allows users who are already authenticated with Okta to access applications secured by Auth0 without logging in again.

Here’s how you can configure Auth0 to use Okta as its Enterprise Identity Provider for SAML SSO.

Setting up Okta as the Identity Provider (IdP)

First, you need to configure Okta to trust Auth0 as a Service Provider.

  1. Create a SAML Application in Okta:

    • Log in to your Okta admin console.
    • Navigate to Applications > Applications.
    • Click Browse App Catalog.
    • Search for "Auth0" and select the Auth0 application.
    • Click Add Integration.
    • On the General Settings tab, give your application a name (e.g., "Auth0 SSO Integration").
    • Click Next.

  2. Configure SAML Settings in Okta:

    • On the Configure SAML tab, you’ll need information from your Auth0 tenant. Keep this tab open.

    • Single sign on URL (ACS URL): This is the endpoint in Auth0 where Okta will send the SAML assertion. It typically looks like https://YOUR_AUTH0_DOMAIN/login/callback?connection=YOUR_OKTA_CONNECTION_NAME. You’ll create this YOUR_OKTA_CONNECTION_NAME in Auth0 later. For now, you can use a placeholder like https://YOUR_AUTH0_DOMAIN/login/callback?connection=okta.

    • Audience URI (SP Entity ID): This uniquely identifies your Auth0 tenant as the Service Provider. It’s usually your Auth0 domain: https://YOUR_AUTH0_DOMAIN.

    • Default Relay State: (Optional) This can be used to redirect users to a specific page after successful authentication.

    • Name ID format: Choose EmailAddress or Unspecified depending on your needs. EmailAddress is common if you’re mapping Okta user emails to Auth0 user emails.

    • Application username: Select Email or Okta username if you want to send the user’s email address as the NameID in the SAML assertion.

    • Attribute Statements: This is crucial for passing user information from Okta to Auth0. You’ll likely want to send at least the user’s email.

      • Click Add Another for email.
      • For Name, enter email.
      • For Name Format, select URI.
      • For Value, select user.email.
      • You might also want to send name (user.firstName + " " + user.lastName) or given_name and family_name separately.

    • Click Next and then Finish.

  3. Get Okta Metadata:

    • After saving the SAML settings, you’ll be on the Sign On tab for your new Okta application.
    • Scroll down to SAML Signing Certificates.
    • Click Actions > View IdP metadata for the active certificate.
    • This will open a new tab with XML content. Save this content, or note the URL of the metadata file. You’ll need this XML (or its URL) for Auth0.

Setting up Auth0 as the Service Provider (SP)

Now, configure Auth0 to accept SAML assertions from Okta.

  1. Create a SAML Enterprise Connection in Auth0:

    • Log in to your Auth0 dashboard.
    • Navigate to Authentication > Enterprise.
    • Click Create Connection.
    • Select SAML.

  2. Configure the SAML Connection in Auth0:

    • Name: This is the connection name you used in Okta’s Single sign on URL. For example, okta.

    • Settings:

      • Identity Provider Metadata:
        • Metadata URL: If Okta provided a metadata URL, paste it here.
        • Metadata XML: Alternatively, paste the entire XML content you copied from Okta here.
      • Service Provider Entity ID: This should match the Audience URI (SP Entity ID) you set in Okta. Usually, it’s your Auth0 domain: https://YOUR_AUTH0_DOMAIN.
      • Assertion Consumer Service URL (ACS URL): This should match the Single sign on URL you set in Okta. It will be https://YOUR_AUTH0_DOMAIN/login/callback?connection=okta (or whatever name you gave your Auth0 connection).
      • Signing Certificate: This is the certificate Auth0 will use to sign SAML requests it sends to Okta (if applicable). You can leave this as default or configure it if needed.
      • Request Authentication Context: This specifies the level of assurance required for authentication. You can leave it as default or configure it based on your security policies.

    • User Profile: This section maps attributes from the SAML assertion (sent by Okta) to user profile properties in Auth0.

      • Email: Map this to the email attribute you configured in Okta.
      • Name: Map this to the name attribute (or given_name and family_name) from Okta.
      • Username: Often mapped to the same as Email.

    • Advanced Settings: (Optional) Configure settings like signing algorithm, encryption, etc., as needed.

    • Click Save.

Testing the Integration

  1. Assign Users in Okta:

    • In Okta, go to your Auth0 SAML application.
    • Navigate to the Assignments tab.
    • Assign users or groups to this application. These are the users who will be able to use Okta to log into Auth0-secured applications.

  2. Test from Auth0:

    • Go to Applications > Applications in your Auth0 dashboard.
    • Select an application that is protected by the "okta" enterprise connection.
    • Click Try Login. This will redirect you to Okta for authentication.
    • After successfully authenticating with Okta, you should be redirected back to your Auth0 application and logged in.

  3. Test from Okta:

    • Users can go to their Okta dashboard, find the Auth0 application icon, and click it. This should initiate an IdP-initiated SSO flow, logging them directly into Auth0.

Key Considerations and Common Issues

  • Clock Skew: Ensure the clocks on your Okta and Auth0 servers are synchronized. Significant time differences can cause SAML assertion validation failures.
  • Entity ID Mismatch: The Audience URI (SP Entity ID) in Okta must exactly match the Service Provider Entity ID in Auth0. This is a very common point of failure.
  • ACS URL Mismatch: The Single sign on URL in Okta must exactly match the Assertion Consumer Service URL (ACS URL) in Auth0. Remember to include the connection name in the Auth0 ACS URL.
  • Attribute Mapping: If users are created in Auth0 but their profile information (like name or email) isn’t populating correctly, double-check the Attribute Statements in Okta and the User Profile mappings in Auth0. Case sensitivity matters for attribute names.
  • Signing Certificates: If Okta’s signing certificate expires or changes, you’ll need to update the metadata in Auth0. Auth0 will also need to trust the new certificate.
  • Connection Name: The connection= part of the Auth0 ACS URL is critical. It must match the Name you give to your SAML connection in Auth0.
  • IdP-Initiated vs. SP-Initiated: Test both ways. Okta-initiated (user clicks app in Okta dashboard) and Auth0-initiated (user tries to access an app secured by Auth0, getting redirected to Okta).

This setup allows Okta to be the single source of truth for user identities, while Auth0 handles application access control and user management for applications that rely on it.

Want structured learning?

Take the full Auth0 course →