## Progressive Summary **Executive Summary (Layer 3)**: **For centralizing authentication across multiple web applications, offload to an SSO-as-a-Service provider unless regulatory requirements mandate self-hosting—the security maintenance burden of running your own Identity Provider is substantial and ongoing.** **Key Insight (Layer 2)**: "OIDC is the modern standard (built on OAuth 2.0, uses JWTs as tokens), but most production systems must support SAML for enterprise/legacy integration. Your IdP becomes a single point of failure—all connected apps go down if it does." **Context (Layer 1)**: - Source: Web research synthesis (January 2026) - Providers compared: Okta, Auth0, Clerk, Keycloak, Azure AD, Cognito - Key decision: Build vs. Buy SSO infrastructure **Cross-Domain Connections**: - [[System Design#Single Point of Failure (SPOF)]] - IdP as critical infrastructure - [[Self-Hosting Decision Framework]] - Control vs. convenience trade-off applies directly - [[Software Design Principles#Separation of Concerns]] - Auth as distinct concern from business logic **Discoverability Score**: 8/10 (high practical value for architectural decisions) **Verification Status**: [Verified] - Multiple sources cross-referenced (see References section) --- Research on authentication approaches for centralizing authentication across multiple web applications. ## Context Need: A single application to handle authentication across multiple web applications (SSO provider pattern). ## Authentication Technologies Overview | Technology | Purpose | Best For | |------------|---------|----------| | **JWT** | Stateless token-based auth | APIs, microservices, mobile apps | | **OAuth 2.0** | Authorization framework | Third-party integrations, delegated access | | **SSO** | Single authentication for multiple apps | Enterprise environments, user convenience | | **SAML** | XML-based enterprise SSO | Large enterprises, legacy systems | | **OpenID Connect (OIDC)** | Identity layer on OAuth 2.0 | Modern SSO, "Login with Google" | ### Key Distinctions - **Authentication (authn)**: Proving identity ("who you are") - **Authorization (authz)**: Access control ("what you can do") - **JWT**: Token format, not a protocol - often combined with OAuth - **OAuth 2.0**: Authorization framework (not authentication) - enables delegated access - **OIDC**: Adds identity/authentication layer on top of OAuth 2.0 ### Common Combinations - **OAuth + JWT**: OAuth handles authorization flow, JWTs serve as access tokens - **OIDC for SSO**: Modern alternative to SAML, uses OAuth infrastructure - **Enterprise stacks**: Often use OIDC internally with SAML support for legacy integrations ## Setting Up Your Own SSO Provider (Identity Provider) ### Required Components 1. **Protocol Implementation** - Support SAML 2.0 and/or OIDC - Most service providers expect one or both protocols 2. **User Directory** - Central store of user credentials and attributes - May integrate with existing LDAP/Active Directory 3. **Token/Assertion Signing** - Cryptographic certificates for signing SAML assertions or JWTs - Certificate rotation and management 4. **Metadata Endpoints** - Configuration URLs for service provider integration - Well-known endpoints for OIDC discovery 5. **Session Management** - Login state handling - Configurable timeouts - Single logout propagation across applications 6. **Multi-Factor Authentication (MFA)** - Increasingly required for enterprise customers - TOTP, SMS, hardware keys, etc. 7. **Error Handling & Monitoring** - Clock synchronization issues - Redirect URI validation - Failed authentication alerts - Session expiry handling ### Security Considerations - **Clock synchronization**: Mismatches break token validation - **Secure redirect URIs**: Prevent open redirect vulnerabilities - **Token expiration/revocation**: JWTs cannot be revoked without additional infrastructure - **Backup access methods**: Plan for IdP downtime - **Regular library updates**: SSO libraries need constant security patching - **Compliance**: GDPR, HIPAA requirements for data protection ### Single Point of Failure Risk If the IdP is compromised or unavailable, all connected applications are affected. Mitigations: - Redundant infrastructure - Active monitoring and alerting - Backup authentication methods - Regular security audits ## SSO-as-a-Service Providers ### Provider Comparison | Provider | Best For | Integrations | SSO Protocols | Self-hosting | Pricing | |----------|----------|--------------|---------------|--------------|---------| | **Okta** | Large enterprise workforce IAM | 7,000+ | SAML, OIDC, LDAP | No | ~$2+/user/month | | **Auth0** | Developer-focused CIAM, B2C/B2B | 85+ | SAML, OIDC, SCIM | Enterprise only | ~$1,400/month for 20K MAU | | **Clerk** | Startups, React/Next.js apps | Growing | SAML, OIDC (premium) | No | Free tier (10K MAU), $25/month+ | | **Azure AD/Entra** | Microsoft ecosystem | Extensive | SAML, OIDC, WS-Fed | No | Varies by tier | | **Amazon Cognito** | AWS-centric applications | AWS services | OIDC, SAML | No | Pay-per-use | | **Keycloak** | Self-hosted, full control | Flexible | SAML, OIDC, LDAP | Yes (required) | Free (self-managed) | ### Detailed Provider Notes #### Okta - Best for managing employee access to business systems - Extensive pre-built integrations (7,000+) - Strong in compliance-heavy, distributed enterprise environments - Identity governance and lifecycle management #### Auth0 (owned by Okta) - Developer-first, API-driven authentication - Flexible for complex scenarios: multi-tenant apps, B2C identity, progressive profiling - Extensible via rules, hooks, and actions - Higher cost but comprehensive feature set #### Clerk - Modern developer experience with pre-built UI components - Excellent for React/Next.js applications - Fastest time-to-implementation - Enterprise SSO only on higher pricing tiers - Less depth in integrations compared to Auth0/Okta #### Keycloak (Open Source) - Full control over infrastructure and data - No licensing costs - Requires self-management: hosting, updates, security patches - Good for regulatory requirements mandating self-hosting ## Decision Framework ### Build Your Own IdP When: - Regulatory/compliance requirements mandate self-hosting - Existing identity infrastructure to leverage - Unique authentication requirements not met by providers - Long-term cost considerations at massive scale ### Use SSO-as-a-Service When: - Faster time to market is priority - Limited identity/security expertise in-house - Need enterprise-grade security without building it - Want ongoing protocol updates handled automatically - Integration breadth is important ### Considerations for Central Auth App If building a central authentication application: 1. **Protocol choice**: OIDC is more modern and easier to implement than SAML 2. **Token strategy**: Short-lived access tokens + refresh tokens 3. **Service provider onboarding**: How will new apps integrate? 4. **User provisioning**: Manual vs. automated (SCIM) 5. **Audit logging**: Required for compliance and debugging ## References - [SSO Implementation Best Practices - Reco](https://www.reco.ai/learn/sso-implementation) - [Session, JWT, SSO, OAuth Comparison - Leapcell](https://leapcell.io/blog/session-jwt-sso-oauth-pros-cons-and-use-cases) - [Okta vs Auth0 Analysis - Infisign](https://www.infisign.ai/blog/auth0-vs-okta) - [10 Best SSO Solutions 2026 - OLOID](https://www.oloid.com/blog/sso-solutions) - [Clerk vs Auth0 - DEV Community](https://dev.to/mechcloud_academy/clerk-vs-auth0-choosing-the-right-authentication-solution-3cfa) - [How to Implement SSO - Auth0](https://auth0.com/learn/how-to-implement-single-sign-on) - [SSO Implementation Blueprint - Scalekit](https://www.scalekit.com/blog/blueprint-for-sso-implementation) ## Status **Decision Pending**: Approach not yet determined. Key decision point: build custom IdP vs. use SSO-as-a-Service provider.