Skip to main content
The SnackBase JavaScript SDK provides multiple authentication methods to secure your applications. This guide explains the authentication model and available options.
SDK v0.3.0 introduced token type detection, authentication method detection, and a new API key format. See What’s New in v0.3.0 for details.

Authentication Methods

SnackBase supports several authentication methods:

Authentication Flow

1. User Authentication

The user provides credentials (email/password, OAuth, or SAML):

2. Token Storage

After successful authentication, the SDK receives:
  • Access Token: Short-lived token for API requests (default: 15 minutes)
  • Refresh Token: Long-lived token for obtaining new access tokens
Tokens are automatically stored based on your storageBackend configuration:

3. Automatic Token Injection

The SDK automatically includes the access token in all API requests via the Authorization header:

4. Automatic Token Refresh

When enableAutoRefresh is true (default), the SDK automatically refreshes the access token before it expires:

Auth State Management

The SDK manages authentication state internally:

Auth Events

Subscribe to authentication state changes:

Multi-Account Users

SnackBase supports users that belong to multiple accounts. After authentication, you can switch accounts:

Session Expiry

Access tokens have a limited lifetime. The SDK handles this automatically:
  1. Before expiry: Token is refreshed automatically (if enableAutoRefresh is true)
  2. After expiry: You’ll receive a 401 error, and the SDK will attempt to refresh
  3. Refresh failure: You’ll need to re-authenticate
Check token expiry:

Logout

Properly log out the current user:
Logging out also disconnects any real-time subscriptions and clears the authentication state from storage.

Choosing an Authentication Method

Email/Password

Use for traditional applications where users create accounts with email and password. Pros:
  • Full control over user data
  • No external dependencies
  • Works offline
Cons:
  • Requires password management
  • Users may forget passwords
When to use:
  • B2B applications
  • Internal tools
  • Apps requiring full user control

OAuth

Use for consumer applications where social login simplifies onboarding. Pros:
  • No password management
  • Faster signup
  • Trusted providers
Cons:
  • Dependent on external providers
  • Less control over user data
When to use:
  • B2C applications
  • Social apps
  • Apps wanting low friction signup

SAML

Use for enterprise customers requiring SSO. Pros:
  • Enterprise standard
  • Centralized user management
  • High security
Cons:
  • Complex setup
  • Requires enterprise identity provider
When to use:
  • B2B enterprise apps
  • Apps with security requirements
  • Integrating with existing enterprise systems

API Keys

Use for server-to-server communication. Pros:
  • No user session required
  • Long-lived credentials
  • Easy to revoke
Cons:
  • Must be kept secret
  • Cannot be used on the client side
When to use:
  • Backend services
  • Cron jobs
  • Webhooks

Next Steps