Skip to content

SAML Auth0 Self-Service Overview

Introduction

Since mid 2025 we onboard people to use the Auth0 SAML integration. We provide a self-service user flow that utilizes the Auth0 self-service feature and let our customers set up the connection themselves.

This approach empowers customers to configure their own SAML connections without requiring extensive manual setup from our team, streamlining the onboarding process and reducing time to integration.

For information on why we require a federated_id claim in SAML connections, see ADR-004: Require federated_id Claim.

Single Logout (SLO)

Single Logout (SLO) is a SAML feature that ensures users are also logged out from the identity provider (IdP) when they log out from our application (the Service Provider). This is important for organizations that require a complete sign-out from all systems, especially in shared device or high-security environments.

Why SLO Matters

When a user logs out from Statista, they typically expect to be logged out from all related systems. Without SLO:

  • Users remain logged into the identity provider
  • In shared device scenarios, the next user could potentially access the previous user's session
  • Organizations with strict security requirements may not meet compliance standards

With SLO enabled:

  • Logging out from Statista triggers a logout request to the IdP
  • The user is signed out from both Statista and their organization's identity system
  • Security is enhanced in multi-tenant and shared environments

Technical Overview

The SLO flow works as follows:

  1. User initiates logout from Statista (Service Provider)
  2. Statista sends a SAML logout request to the IdP's SingleLogoutService URL
  3. The IdP terminates the user's session
  4. The IdP sends a logout response back to Statista
  5. Both sessions are now terminated

For this to work correctly:

  • The IdP must support and enable SLO
  • The Auth0 connection must have SLO enabled
  • Connection metadata must include the slo_enabled=true flag
  • The __sso cookie must correctly persist the sloEnabled flag

References