Overview
SnackBase authentication is built for enterprise multi-account scenarios:User Identity Model
In SnackBase, a user’s identity is defined by a tuple:[email protected]in accountAB1001= User Identity #1[email protected]in accountXY2048= User Identity #2- These are different users with different passwords
Account Registration
Account registration creates a new tenant/workspace in SnackBase.Account ID Format
Accounts use two identifiers:- id (UUID): Primary key, immutable, globally unique
- account_code (XX####): Human-readable format for display
- Format: 2 letters + 4 digits (e.g., AB1001, XY2048)
- Sequential generation for easy reference
- Used in UI and exports
- slug: URL-friendly identifier for login
- name: Display name (not unique)
User Registration
User registration creates a new user within a specific account.Registration Flow
Email Uniqueness
Email uniqueness is scoped to account:Email Verification
Email verification is required before users can log in to their accounts.Verification Flow
Verification Token Model
- Tokens are hashed with SHA-256 before storage (never stored in plaintext)
- Tokens expire after 1 hour
- Tokens are single-use (deleted after verification)
- Token hash uses constant-time comparison to prevent timing attacks
Login Requirement
Users cannot login until their email is verified:Login Flow
Login authenticates a user and issues JWT tokens.Login Process
Timing-Safe Password Comparison
SnackBase uses timing-safe comparison to prevent timing attacks:Token Management
SnackBase uses JWT (JSON Web Tokens) with access and refresh tokens, with true token rotation for enhanced security.Token Types
Access Token Structure
Refresh Token Structure
jti (JWT ID) claim uniquely identifies each refresh token and is used to track revocation.
Token Refresh with Rotation
- Old refresh token is marked as revoked in database
- New refresh token is generated and stored (hash)
- Old token cannot be used again (returns 401 if attempted)
- Each refresh creates a new token in the chain
OAuth 2.0 Authentication
SnackBase supports OAuth 2.0 / OpenID Connect authentication for popular social and enterprise identity providers.Supported OAuth Providers
OAuth Flow
SAML 2.0 Authentication
SnackBase supports SAML 2.0 for enterprise single sign-on (SSO) with identity providers like Okta, Azure AD, and other SAML-compliant systems.Supported SAML Providers
SAML Flow
Multi-Account Users
SnackBase supports enterprise multi-account scenarios where users can belong to multiple accounts.User Identity Matrix
- Same email can exist in multiple accounts
- Each
(email, account_id)tuple has a unique password - Users must specify account when logging in
Login with Account Selection
When logging in, users must specify which account they’re accessing: Option 1: Account in URL (subdomain)API Key Authentication
API keys provide an alternative authentication method designed for service-to-service communication, CLI tools, and integrations where JWT token management is impractical.When to Use API Keys
API Key Format
API keys follow a structured format:sb_sk_AB1234_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
Components:
sb_sk- SnackBase Secret Key prefix (identifies the key type)AB1234- Account code (human-readable account identifier)a1b2c3...o5p6- 32-character cryptographically secure random string
API Key Authentication Flow
API Key Data Model
- SHA-256 Hashing: Keys are hashed before storage (plaintext never persisted)
- Single-User Association: Each key is linked to one user in one account
- Immediate Revocation: Keys can be revoked instantly
- Audit Trail: Tracks creation, last used, and revocation
- Account Scoping: Keys are automatically scoped to their account
Authentication Comparison
Creating API Keys
Via API:- Navigate to Settings → API Keys
- Click “Create API Key”
- Enter name and description
- Copy the displayed key (shown only once)
- Store securely in your application
Using API Keys
API keys use the standardAuthorization: Bearer header:
Managing API Keys
List API Keys:Security Best Practices
1. Secure Storage:- Environment (Production, Staging, Development)
- Service (Payment Service, Webhook Handler, CLI)
- Purpose (Backup Job, Monitoring Integration)
- Immediately revoke the compromised key
- Create a replacement key
- Update all services using the old key
- Investigate potential unauthorized access
- Review audit logs for suspicious activity
API Key vs User Permissions
API keys inherit the permissions of the user who created them:- Create dedicated service users with minimal required permissions
- Don’t use personal admin accounts to create production API keys
- Regularly audit which users have created API keys