Identity and Access Architecture

Executive Summary

The bondingAI Platform uses WorkOS exclusively for authentication and authorization. This document addresses concerns about external traffic and demonstrates why this architecture is the optimal choice for enterprise deployments.

Key Point: WorkOS handles only identity verification. Zero business data (chats, documents, AI responses, analytics) leaves the customer's cloud environment.

Architecture Overview

Data Flow Separation

The following diagram illustrates the clear boundary between business data (which remains entirely within the customer's Azure environment) and authentication data (handled by WorkOS).

Authentication Flow

Data Classification

Data Category	Examples	Storage Location	Leaves Customer Cloud
Chat Content	Messages, AI responses, conversation history	Customer PostgreSQL	No
Documents	Uploaded files, PDFs, knowledge base	Customer Azure Blob	No
Embeddings	Vector representations, RAG data	Customer PGVector	No
Analytics	Usage metrics, KPIs, dashboards	Customer PostgreSQL	No
Company Data	Organizations, domains, configurations	Customer PostgreSQL	No
User Identity	Email, name, organization membership	WorkOS	Yes (auth only)
SSO Config	SAML/OIDC provider settings	WorkOS	Yes (auth only)
Access Tokens	JWT tokens for session management	WorkOS	Yes (auth only)

WorkOS Security and Compliance

WorkOS maintains enterprise-grade security certifications and compliance standards:

Certification	Status	Description
SOC 2 Type 2	Certified	Annual audit of security controls, availability, and confidentiality
GDPR	Compliant	European data protection regulation compliance
CCPA	Compliant	California Consumer Privacy Act compliance
HIPAA	BAA Available	Business Associate Agreement available for healthcare customers
PCI DSS	Certified	Payment Card Industry Data Security Standard

Security Practices:

Annual third-party penetration testing
External code audits
Encrypted data at rest and in transit (TLS 1.3)
Trust Center with publicly available compliance documentation
Data Processing Addendum (DPA) available

WorkOS processes only the data sent from identity providers during authentication. No business application data is transmitted to or stored by WorkOS.

Why Not Alternative Solutions

Cost Impact

Replacing WorkOS with alternative solutions such as Microsoft Entra External ID, Auth0, or a custom-built authentication system would result in drastically increased costs for the customer:

Cost Category	With WorkOS	With Alternative
Implementation Timeline	Ready to go	~ 2-3 months
Custom Admin Portal	Included	Must build
Directory Sync (SCIM)	Included	Additional licensing or custom development
Ongoing Maintenance	Included	Customer responsibility

Feature Gap

Removing WorkOS means losing access to enterprise-ready features that would need to be rebuilt:

Admin Portal: Built-in self-service portal for customer IT administrators to configure SSO and directory sync without vendor support
Directory Sync: Automatic user provisioning/deprovisioning from Azure AD, Okta, Google Workspace
Multi-IdP Support: Simplified integration with multiple identity providers per organization
Fine-Grained Authorization (FGA): Resource-level permission management

Development Burden

Capability	WorkOS	Custom/Alternative
SSO Configuration UI	Built-in Admin Portal	Must design and build
SCIM Implementation	Turnkey	Must implement SCIM server
Multi-tenant Organizations	Native support	Must architect
Enterprise SSO (SAML/OIDC)	Pre-built connectors	Must build each integration

Risk Analysis

Risks of Replacing WorkOS

Risk	Impact	Mitigation Effort
Extended development timeline	2-3x longer implementation	Significant
Custom admin portal required	High development cost	High
Maintenance burden shifts to customer	Ongoing operational cost	Permanent
Loss of enterprise B2B features	Reduced competitiveness	Requires custom development
Security responsibility transfer	Customer must maintain auth security	Continuous

Why External Authentication Traffic is Acceptable

The separation of authentication from business data is a recognized architectural best practice adopted by leading technology companies:

Industry Adoption:

Vercel, Netlify, Webflow use WorkOS for authentication
OpenAI and Slack separate authentication traffic from business data
Plaid and other fintech companies follow this pattern

Technical Rationale:

Authentication tokens contain only identity claims (who the user is)
Business data (what the user does) never traverses external networks
JWT validation uses public JWKS endpoints (cryptographic verification, no data exposure)
TLS 1.3 encryption protects all authentication traffic

Compliance Alignment:

SOC 2, GDPR, and HIPAA frameworks recognize the distinction between identity data and business data
Authentication-as-a-Service is an accepted pattern for regulated industries

Summary

The bondingAI Platform architecture maintains a clear separation between:

Concern	Handled By	Location
Identity (who is the user)	WorkOS	External (secure)
Business Data (what the user does)	Customer Azure	Internal (customer-controlled)

Benefits of Current Architecture:

Data Sovereignty: All business data remains within the customer's Azure environment
Enterprise Security: SOC 2 Type 2, GDPR, HIPAA-ready authentication infrastructure
Reduced Complexity: Pre-built enterprise features eliminate custom development
Cost Efficiency: Included features would cost significantly more to build and maintain
Industry Standard: Architecture pattern validated by leading B2B SaaS companies

Replacing WorkOS would increase implementation costs, extend timelines, and shift ongoing security and maintenance responsibilities to the customer without improving data privacy, as business data already remains entirely within the customer's environment.

Identity and Access Architecture

On this page