Skip to main content
SnackBase provides a comprehensive authentication system designed for multi-tenant applications. This guide explains authentication flows, token management, API keys, multi-account users, email verification, OAuth/SAML integration, and security considerations.

Overview

SnackBase authentication is built for enterprise multi-account scenarios:

User Identity Model

In SnackBase, a user’s identity is defined by a tuple:
This means:

Account Registration

Account registration creates a new tenant/workspace in SnackBase.

Account ID Format

Accounts use two identifiers:
Properties:
  • 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

Security Properties:
  • 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

The jti (JWT ID) claim uniquely identifies each refresh token and is used to track revocation.

Token Refresh with Rotation

True Token Rotation:
  1. Old refresh token is marked as revoked in database
  2. New refresh token is generated and stored (hash)
  3. Old token cannot be used again (returns 401 if attempted)
  4. 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

Key Points:
  • 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)
Option 2: Account in Request Body

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:
Example: 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

Security Properties:
  • 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:
Via Admin UI:
  1. Navigate to Settings → API Keys
  2. Click “Create API Key”
  3. Enter name and description
  4. Copy the displayed key (shown only once)
  5. Store securely in your application

Using API Keys

API keys use the standard Authorization: Bearer header:
In Code:

Managing API Keys

List API Keys:
Response (metadata only, no full keys):
Revoke API Key:
Get Key Details:

Security Best Practices

1. Secure Storage:
2. Key Rotation:
3. Scoping and Naming:
Use descriptive names to identify:
  • Environment (Production, Staging, Development)
  • Service (Payment Service, Webhook Handler, CLI)
  • Purpose (Backup Job, Monitoring Integration)
4. Monitoring and Auditing:
5. Revocation on Compromise: If an API key is accidentally exposed (committed to repo, logged, etc.):
  1. Immediately revoke the compromised key
  2. Create a replacement key
  3. Update all services using the old key
  4. Investigate potential unauthorized access
  5. Review audit logs for suspicious activity

API Key vs User Permissions

API keys inherit the permissions of the user who created them:
This means:
  • 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

Common Patterns

Service Authentication:
CLI Tool:
Webhook Handler:

Security Features

Password Hashing (Argon2id)

SnackBase uses Argon2id, the OWASP-recommended password hashing algorithm:

Password Requirements

Default password requirements (configurable):

Token Expiration

Best Practices

1. Token Storage

For Web Applications:

2. Token Refresh

Implement proactive token refresh:

3. Handle Token Expiration

4. Logout Properly

5. Use HTTPS in Production

Never send tokens over unencrypted connections:

Summary