Security & Authentication Architecture
Enterprise-grade security with JWT-based authentication, role-based access control, and PostgreSQL row-level security.
NEON Security Architecture
Our security architecture implements defense-in-depth with multiple authentication layers, database-level access controls, and cryptographic token management. Every component is designed to fail securely and maintain audit trails.
Authentication Services (GoTrue & PostgREST)
GoTrue (OAuth2 Server)
Industry-standard OAuth2 authentication server built on Supabase Auth. Handles user registration, login, password resets, and session management with secure, short-lived JWT tokens.
- •Email/password authentication with bcrypt hashing
- •Magic link authentication (passwordless login)
- •OAuth providers (Google, GitHub, etc.)
- •Automatic token refresh and rotation
PostgREST (API Gateway)
Automatically generates RESTful APIs from PostgreSQL schemas with built-in JWT validation. Every API request is authenticated and authorized at the database level.
- •JWT signature verification on every request
- •Automatic schema-to-API mapping
- •CORS and rate limiting enforcement
- •Query filtering and pagination
JWT Token Structure
Shared JWT Secret
Both GoTrue and PostgREST share a cryptographic secret for signing and verifying JWTs. This ensures tokens issued by GoTrue are trusted by PostgREST without round-trip validation.
Token Payload (Decoded)
{
"sub": "user-uuid-here",
"email": "user@example.com",
"role": "authenticated",
"aud": "authenticated",
"exp": 1735678901,
"iat": 1735675301,
"user_metadata": {},
"app_metadata": {
"provider": "email"
}
}JWT Configuration
Required for PostgREST to grant access. All authenticated users get this role.
Short-lived tokens reduce attack surface. Automatic refresh keeps users logged in.
Database Layer Security
PostgreSQL Row-Level Security (RLS)
Every table has RLS policies that enforce access control at the database level. Even if an attacker bypasses the application layer, the database itself prevents unauthorized data access.
-- Users can only see their own deployments
CREATE POLICY "user_read_own_deployments"
ON deployments FOR SELECT
USING (auth.uid() = user_id);
-- Filtered access via email
RLS POLICY with checks: user_email
WHERE user_email = current_setting('request.jwt.claims', true)::json->>'email'
AND (user_email LIKE '%@helpers' OR user_email = 'admin@helpers');Password Hashing (PGCRYPTO)
All passwords are hashed using PostgreSQL's pgcrypto extension with bcrypt. Plaintext passwords never touch the database—only irreversible cryptographic hashes are stored.
-- Credentials table with encrypted passwords CREATE TABLE cloud_credentials ( id uuid PRIMARY KEY, user_id uuid REFERENCES auth.users(id), encrypted_password text, -- bcrypt hash created_at timestamptz DEFAULT now() ); -- Passwords automatically hashed on insert/update CONTRACTOR ID: Automatic via pgcrypto.crypt() ACCESS TOKEN: JWT-signed session tokens only
Audit Logging
Every authentication event, failed login attempt, and database modification is logged with timestamps and user context. Immutable audit trail for compliance and forensic analysis.
Cookie Configuration & Session Management
Authentication tokens are stored in secure, HTTP-only cookies with strict domain and SameSite policies to prevent cross-site attacks and cookie hijacking.
Cookie Attributes
- Name: sb-purelogic-auth-token
- Domain: .purelogic.studio
- SameSite: lax
- Secure: true (HTTPS only)
- HttpOnly: true (no JS access)
Benefits
- ✓Cross-subdomain authentication (deploy.purelogic.studio, api.purelogic.studio)
- ✓XSS protection via HttpOnly flag
- ✓CSRF protection via SameSite lax
- ✓TLS-only transmission prevents interception
Security Best Practices Implemented
Defense in Depth
Multiple security layers: application-level auth, API gateway validation, database RLS, and network segmentation. Compromise of one layer doesn't breach the entire system.
Least Privilege Access
Users only get the minimum permissions required for their role. Database service accounts have scoped access to specific schemas and operations.
Secrets Management
JWT secrets, database credentials, and API keys stored in Kubernetes secrets or AWS Secrets Manager. Never hardcoded in application code or environment variables.
Fail Securely
On authentication failure, the system denies access by default. No fallback to insecure modes or permissive error handling that could leak sensitive information.
Compliance & Certifications
Our security architecture is designed to meet enterprise compliance requirements:
Data Protection
- •GDPR: Right to be forgotten, data portability, encryption at rest
- •HIPAA: PHI encryption, access logging, BAA-compliant hosting
- •SOC 2: Audit trails, change management, incident response
Security Controls
- •TLS 1.3 encryption for all network traffic
- •AES-256 encryption at rest for all databases
- •Automated vulnerability scanning and patching
Security-First Automation
Don't trust your automation to SaaS platforms with shared infrastructure and unknown security practices. Schedule a Logic Audit to see how we architect secure, compliant automation infrastructure.
Schedule Your Logic Audit