Auth0Connection: Technical Research Documentation

Introduction

Auth0 is a leading identity-as-a-service (IDaaS) platform that provides authentication, authorization, and user management capabilities. At the core of Auth0's architecture are connections - the bridges between applications and identity sources.

This document provides comprehensive research into Auth0 connections, their configuration landscape, and the rationale behind Project Planton's Auth0Connection deployment component design.

The Evolution of Identity Management

From Custom Authentication to Identity Platforms

The authentication landscape has evolved significantly:

1. Custom Database Authentication (1990s-2000s)

   • Applications built their own user databases
   • Password hashing, session management, security all custom-built
   • High security burden on developers

2. OAuth/OpenID Connect Era (2010s)

   • Standardized protocols for delegated authentication
   • "Login with Google/Facebook" became ubiquitous
   • Still required significant integration work

3. Identity-as-a-Service (2015-present)

   • Auth0, Okta, Firebase Auth abstract complexity
   • Unified APIs for multiple identity sources
   • Built-in security best practices

Why Auth0 Connections Matter

Connections in Auth0 serve as:

• Abstraction Layer: Unified API regardless of identity source
• Security Boundary: Consistent security policies across providers
• Integration Point: Single configuration for multiple applications
• Compliance Enabler: Audit trails and policy enforcement

Auth0 Connection Types

1. Database Connections

Auth0's hosted user database (strategy: auth0) provides:

Features:

• Secure password storage (bcrypt hashing)
• Configurable password policies
• Brute force protection
• Password history enforcement
• User metadata storage

Use Cases:

• Consumer applications requiring email/password signup
• Applications needing full user profile control
• Scenarios where social login isn't appropriate

Configuration Complexity:

• Password policy selection (none → excellent)
• Username requirements
• MFA enforcement
• Custom database scripts (advanced)

2. Social Connections

Social identity providers (Google, Facebook, GitHub, etc.) enable:

Features:

• OAuth 2.0/OpenID Connect integration
• Automatic profile population
• Reduced signup friction
• Trust in established providers

Supported Providers:

Configuration Requirements:

• OAuth app credentials from provider
• Scope selection based on data needs
• Callback URL configuration

3. Enterprise Connections

Enterprise identity providers enable Single Sign-On (SSO):

SAML (strategy: samlp):

• Industry standard for enterprise SSO
• Supports Okta, OneLogin, ADFS, PingFederate
• XML-based protocol
• Requires certificate management

OpenID Connect (strategy: oidc):

• Modern alternative to SAML
• JSON/REST-based
• Supports Keycloak, Ping Identity, custom providers
• Dynamic discovery via .well-known/openid-configuration

Azure AD / Entra ID (strategy: waad):

• Native Microsoft integration
• Group synchronization
• Directory API access
• Multi-tenant support

Active Directory (strategy: ad):

• On-premises AD integration
• Requires AD/LDAP Connector
• Kerberos/NTLM support

Deployment Methods: Landscape Analysis

Manual Configuration (Auth0 Dashboard)

Pros:

• Visual interface
• Immediate feedback
• Good for exploration

Cons:

• No version control
• Manual reproduction across environments
• Prone to configuration drift
• Not auditable

Auth0 Deploy CLI

Auth0's official configuration-as-code tool:

Pros:

• YAML/JSON configuration files
• CI/CD integration
• Environment-specific overrides

Cons:

• Auth0-specific tooling
• Learning curve for syntax
• Limited cross-platform integration

Terraform

HashiCorp's infrastructure-as-code approach:

Pros:

• Industry standard IaC
• State management
• Plan/apply workflow
• Large community

Cons:

• Requires Terraform expertise
• State file management complexity
• HCL learning curve

Auth0 Provider Resources:

• auth0_connection - Connection configuration
• auth0_connection_client - Client enablement
• auth0_connection_scim_configuration - SCIM setup

Pulumi

Programming language-based IaC:

Pros:

• Full programming language (Go, Python, TypeScript)
• Type safety
• IDE support
• Reusable components

Cons:

• Requires programming knowledge
• Less declarative than Terraform
• Smaller community for Auth0

Auth0 Provider:

• auth0.Connection - Connection resource
• Full TypeScript/Go type definitions

Project Planton's Approach

80/20 Scoping Decision

Based on research, the following features cover 80% of use cases:

In Scope:

1. Database connections with password policies
2. Major social providers (Google, Facebook, GitHub, LinkedIn, Twitter, Microsoft, Apple)
3. Enterprise SSO via SAML, OIDC, and Azure AD
4. Security controls (brute force, password history, MFA)
5. Client enablement and realm configuration
6. Domain-based discovery for enterprise SSO

Out of Scope (20% edge cases):

1. Custom database action scripts
2. Passwordless connections (SMS, email link)
3. Active Directory connector configuration
4. Connection-level rate limiting
5. Custom social providers
6. SCIM provisioning configuration

Rationale:

• Custom scripts require runtime environment (Lambda, etc.)
• Passwordless requires additional infrastructure (Twilio, SendGrid)
• AD connector is infrastructure, not just configuration
• Rate limiting is rarely customized per-connection
• Custom social providers are rare

Design Decisions

1. Strategy-Specific Options

Rather than a flat structure with all possible fields, we use strategy-specific option blocks:

• database_options for auth0 strategy
• social_options for social strategies
• saml_options for samlp strategy
• oidc_options for oidc strategy
• azure_ad_options for waad strategy

Rationale: Prevents confusion about which fields apply to which strategy.

2. Sensible Defaults

All optional fields have production-appropriate defaults:

• password_policy: "good" (not "none")
• brute_force_protection: true
• password_dictionary: true

Rationale: Secure by default; users opt-out of security, not opt-in.

3. Validation Rules

Proto validations enforce:

• Required strategy field with allowed values
• Required credentials for each strategy type
• Numeric ranges (password_history_size: 0-24)
• Enum values for password policies, signature algorithms

Rationale: Fail fast at manifest validation, not at deployment time.

Implementation Landscape

Terraform Implementation

The Terraform module uses:

• auth0_connection resource
• Dynamic blocks for strategy-specific options
• Local values for computed configuration
• Conditional resource arguments based on strategy

Pulumi Implementation

The Pulumi module uses:

• auth0.Connection resource
• Go struct for locals
• Strategy switch for option building
• Type-safe configuration

Feature Parity

Both implementations support identical features:

• All connection strategies
• All option configurations
• All output values

Production Best Practices

Security

1. Password Policies: Use "good" or "excellent" for production
2. Brute Force: Always enable brute force protection
3. MFA: Consider MFA for high-security applications
4. Password History: Prevent password reuse (5-10 entries)

Operations

1. Client Scoping: Only enable connections for applications that need them
2. Environment Separation: Different connections per environment when needed
3. Monitoring: Monitor connection usage and failures via Auth0 logs
4. Rotation: Regularly rotate OAuth client secrets

Enterprise SSO

1. Certificate Management: Track certificate expiration for SAML
2. Domain Verification: Verify domains before enabling domain connections
3. Group Mapping: Map IdP groups to Auth0 roles/permissions
4. Just-in-Time Provisioning: Understand JIT provisioning implications

Common Pitfalls

1. Missing Client Enablement

Creating a connection without enabling it for any clients results in an unusable connection. Always specify enabled_clients.

2. Incorrect OAuth Callback URLs

Social and enterprise connections require correct callback URLs registered with the identity provider. Auth0's callback URL format: https://{tenant}.auth0.com/login/callback

3. Certificate Expiration

SAML certificates expire and must be rotated. Monitor expiration dates.

4. Scope Creep

Requesting too many scopes from social providers can trigger additional review processes (Facebook, Google).

5. Multi-Tenant Confusion

For Azure AD, misunderstanding use_common_endpoint vs tenant-specific configuration leads to authentication failures.

Conclusion

Auth0 connections are the fundamental building blocks of identity integration. Project Planton's Auth0Connection component provides a declarative, secure-by-default approach to managing these connections across multiple strategies.

By focusing on the 80% use case while providing comprehensive options for common scenarios, this component enables teams to:

• Standardize authentication configuration
• Version control identity infrastructure
• Maintain consistency across environments
• Apply security best practices automatically

The dual IaC implementation (Pulumi and Terraform) ensures flexibility in deployment tooling while the KRM-style manifest provides a familiar, declarative interface for platform engineers.