Authentication & Security Architecture

The security architecture in sfp server addresses the challenge of managing sensitive credentials across multiple systems. The platform must handle Salesforce organization credentials, Git provider tokens, and various integration secrets while maintaining strict isolation between tenants and ensuring credentials are never exposed beyond their intended scope.

Credential Security Model

The credential security model is built around the principle that secrets should exist in memory only for the duration they are needed. Credentials are stored in Supabase with encryption at rest using a dedicated encryption key, and are never persisted to disk in plaintext within the application runtime.

When a worker begins execution, it requests only the specific credentials required for its assigned task from Supabase. These credentials are decrypted using the encryption key and loaded into the worker's memory space. Upon task completion or termination, the credentials are explicitly cleared before the worker container is destroyed. This just-in-time access pattern ensures that credentials are scoped to individual task executions rather than being broadly available across the system.

Secret Storage

All credentials are encrypted at rest using a dedicated encryption key before being stored in Supabase. The encryption happens at the application layer, meaning the database stores only ciphertext. The system maintains separation between different credential types, with Salesforce org credentials, Git provider tokens, and API keys stored in distinct tables with appropriate access controls.

Secret rotation is supported through the management API. When credentials are rotated, the new values are encrypted and stored, taking effect for subsequent task executions without requiring system restarts. The previous credential versions can be retained according to configurable retention policies to support audit requirements.

Access Control for Credentials

Credential access is governed by the same role-based access control system that protects other platform resources. Production Salesforce org credentials require elevated permissions, ensuring that only authorized users and application tokens can trigger operations against production environments. Development and sandbox credentials follow a more permissive access model appropriate for iterative development workflows.

All credential access is logged with full context including the requesting identity, the task that required the credential, and the timestamp. These audit records are retained in the database and can be queried for compliance reporting and security investigations.

Tenant Isolation

Each organization operates with complete credential isolation. Since each organization has its own dedicated Supabase instance, credentials from one organization are physically separated from another at the database level. This isolation extends to the worker execution environment, where each task runs in a container that has no visibility into other tenants' resources or credentials.

The isolation model ensures that a security incident affecting one tenant cannot propagate to others. Even in the event of a compromised worker, the blast radius is limited to the specific credentials that were loaded for that particular task execution.

Secure Communication

All communication channels in the system use TLS encryption. API calls between clients and the server, WebSocket connections for real-time updates, and internal service-to-service communication all operate over encrypted channels. OAuth flows for authentication providers are conducted through secure redirect chains, with tokens transmitted only over encrypted connections.

The edge layer (Caddy) handles TLS termination for external traffic, presenting valid certificates and enforcing modern cipher suites. Internal traffic within the Docker network operates over the isolated bridge network, with services communicating through their internal hostnames rather than public endpoints.