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:| Method | Use Case | Location |
|---|---|---|
| Email/Password | Traditional web applications | Client + Server |
| OAuth | Social login (Google, GitHub, etc.) | Client |
| SAML | Enterprise SSO | Client |
| API Keys | Server-to-server communication | Server Only |
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
storageBackend configuration:
3. Automatic Token Injection
The SDK automatically includes the access token in all API requests via theAuthorization header:
4. Automatic Token Refresh
WhenenableAutoRefresh 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:- Before expiry: Token is refreshed automatically (if
enableAutoRefreshis true) - After expiry: You’ll receive a 401 error, and the SDK will attempt to refresh
- Refresh failure: You’ll need to re-authenticate
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
- Requires password management
- Users may forget passwords
- 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
- Dependent on external providers
- Less control over user data
- B2C applications
- Social apps
- Apps wanting low friction signup
SAML
Use for enterprise customers requiring SSO. Pros:- Enterprise standard
- Centralized user management
- High security
- Complex setup
- Requires enterprise identity provider
- 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
- Must be kept secret
- Cannot be used on the client side
- Backend services
- Cron jobs
- Webhooks
Next Steps
- Email/Password Auth - Implement traditional authentication
- OAuth Guide - Set up social login
- API Keys - Use API keys for server operations