Auth0 doesn’t just integrate with SAML; it is the SAML IdP for your enterprise identity provider, acting as the crucial intermediary that translates your existing user directory into a language modern apps understand.
Let’s see Auth0 in action as a SAML IdP. Imagine a user trying to access a protected application.
- User attempts to access App X. The app, configured to trust Auth0 as its SAML IdP, redirects the user’s browser to Auth0’s login page.
- Auth0 prompts for authentication. This is where Auth0 shines. It can delegate authentication to your existing enterprise directory (like Active Directory via ADFS, Azure AD, Okta, etc.) using SAML, or it can handle authentication itself with its own user database and MFA options.
- If delegating, Auth0 redirects to the Enterprise IdP. The user is sent to their company’s SAML IdP (e.g., ADFS).
- Enterprise IdP authenticates the user. The user provides their corporate credentials.
- Enterprise IdP sends a SAML assertion back to Auth0. This assertion is a cryptographically signed XML document containing user identity information (like email, name, groups).
- Auth0 processes the assertion. It validates the signature and extracts the user attributes.
- Auth0 generates its own SAML assertion. This assertion is tailored for App X, containing the attributes App X expects. Crucially, Auth0 can transform, filter, or enrich the attributes received from the enterprise IdP.
- Auth0 sends its SAML assertion back to the user’s browser.
- The browser posts the assertion to App X.
- App X validates Auth0’s assertion. It checks the signature, verifies the issuer (Auth0), and extracts the user attributes. The user is now logged into App X.
This flow means your enterprise users can use their existing corporate credentials to access any application that supports SAML, with Auth0 acting as the central, flexible orchestrator.
The core problem Auth0 solves here is application onboarding. Instead of configuring SAML for every single application against your enterprise IdP (which can be a nightmare of duplicate work, differing SAML specs, and complex certificate management), you configure SAML once between your enterprise IdP and Auth0. Then, for each new application, you simply configure a SAML connection within Auth0. Auth0 handles the rest, translating between your enterprise SAML profile and the specific SAML profile each application requires. This dramatically reduces the effort and risk involved in integrating new SaaS or internal applications.
Internally, Auth0’s SAML connections are configured with two primary pieces of information:
- Your Enterprise IdP’s SAML Metadata: This tells Auth0 how to trust your IdP. It includes the IdP’s signing certificate, its SSO endpoint URL, and its entity ID.
- Your Application’s SAML Metadata: This tells Auth0 how to trust the application and what kind of SAML assertion it expects. It includes the application’s signing certificate (if it signs assertions), its Assertion Consumer Service (ACS) URL, and its entity ID.
Auth0 uses these configurations to perform the cryptographic validation and attribute transformation. You control which attributes are sent to the application, whether Auth0 signs its assertions, and how user identities are mapped.
The most surprising mechanical detail is how Auth0 handles the "Service Provider" (SP) role for your applications. When Auth0 acts as an IdP for an application, it effectively becomes the SAML Service Provider for that application. It receives the SAML request from the application, redirects the user to your enterprise SAML IdP, receives the assertion from your enterprise IdP, transforms it, and then sends its own SAML assertion back to the application. This "IdP of an IdP" pattern is what allows for such flexible attribute mapping and centralized control.
The next logical step is to explore how Auth0’s Rules and Hooks can be used to dynamically transform and enrich SAML assertions before they are sent to your applications.