Authentication Providers and Methods
Multiple Paths to Identity
Supabase supports numerous authentication methods. Choosing the right one depends on your application's needs, your users' expectations, and security requirements.
Email/Password Authentication
The traditional approach that users understand.
How It Works
1. User provides email + password
2. Server validates credentials
3. Returns JWT token on success
Advantages
- Familiar: Users know how it works
- No third parties: Complete control
- Works offline: No OAuth dependencies
Considerations
- Password management: Users forget passwords
- Security burden: You handle credential storage
- Friction: Requires email verification
Best Practices
- Require email confirmation
- Enforce strong passwords
- Implement rate limiting
- Provide password reset flow
Magic Links (Passwordless Email)
User receives a login link via email—no password needed.
How It Works
1. User enters email address
2. Server sends email with special link
3. User clicks link
4. Server validates token, logs user in
Advantages
- No passwords to remember: Reduces friction
- Email proves identity: Like email-based 2FA
- No credential storage: Simpler security model
Considerations
- Email access required: Can't log in without email
- Delivery delays: Users wait for email
- Shared device risk: Email links can be intercepted
When to Use
- Consumer apps prioritizing ease of use
- Apps where users authenticate infrequently
- When you want to avoid password reset flows
Phone/SMS Authentication
One-time codes sent via SMS.
How It Works
1. User enters phone number
2. Server sends SMS with 6-digit code
3. User enters code
4. Server validates code, logs user in
Advantages
- Device-based: Phone number tied to device
- Familiar UX: Similar to banking apps
- No password: Reduces friction
Considerations
- SMS costs: Pay per message sent
- SIM swapping: Security vulnerability
- International challenges: Different formats, costs
- Delivery reliability: SMS can be delayed
When to Use
- Mobile-first applications
- Markets where phone is primary identifier
- When phone verification adds business value
OAuth Providers
Let users sign in with existing accounts from other services.
Supported Providers
Supabase supports many OAuth providers:
| Provider | Use Case |
|---|---|
| General consumer apps | |
| GitHub | Developer tools |
| GitLab | Developer tools |
| Apple | iOS apps (required by App Store) |
| Microsoft | Enterprise, B2B |
| Consumer social apps | |
| Social apps | |
| Discord | Gaming, communities |
| Slack | Workspace tools |
| Professional apps | |
| Twitch | Streaming, gaming |
| Spotify | Music-related apps |
How OAuth Works
┌─────────┐ ┌─────────┐ ┌─────────────┐
│ Your │ │Supabase │ │ OAuth │
│ App │ │ Auth │ │ Provider │
└────┬────┘ └────┬────┘ └──────┬──────┘
│ │ │
│ 1. Click "Sign in with Google" │
│─────────────────│ │
│ │ │
│ 2. Redirect to Google │
│←─────────────────────────────────────
│ │ │
│ 3. User approves │
│─────────────────────────────────────→
│ │ │
│ 4. Redirect back with code │
│←─────────────────────────────────────
│ │ │
│ 5. Forward code │ │
│─────────────────→ │
│ │ │
│ │ 6. Exchange code │
│ │ for tokens │
│ │──────────────────→│
│ │ │
│ │ 7. Get user info │
│ │←──────────────────│
│ │ │
│ 8. Create/update user │
│ 9. Issue Supabase JWT │
│←────────────────│ │
Advantages
- Reduced friction: One-click signup
- No password management: Provider handles it
- Verified emails: Usually pre-verified
- Rich profile data: Name, avatar, etc.
Considerations
- Provider dependency: If provider is down, users can't log in
- Privacy concerns: Some users avoid OAuth
- Account linking: Same email, different providers
- Provider changes: APIs can change
When to Use
- Consumer apps where conversion matters
- Developer tools (GitHub is expected)
- Apps targeting specific platforms
Single Sign-On (SSO/SAML)
Enterprise authentication for organizations.
How It Works
1. User enters company email
2. Redirect to company's identity provider (Okta, Azure AD, etc.)
3. User authenticates with corporate credentials
4. Provider returns SAML assertion
5. Supabase validates assertion, issues JWT
Advantages
- Enterprise requirement: Many companies mandate SSO
- Centralized control: IT manages access
- Compliance: Audit trails, policy enforcement
- Employee experience: One password for everything
Considerations
- Complex setup: Requires coordination with IT
- Higher tier required: Not in free tier
- Maintenance: Certificate rotation, metadata updates
When to Use
- B2B SaaS applications
- Apps selling to enterprises
- Internal corporate tools
Anonymous Authentication
Let users use your app without signing up.
How It Works
1. User opens app
2. Supabase creates anonymous user with UUID
3. Issues JWT with 'anon' role
4. User can later "upgrade" to full account
Advantages
- Zero friction: Immediate access
- Data persistence: Can save progress
- Gradual engagement: Convert when ready
Considerations
- Data ownership unclear: Users may not return
- Account linking: Converting anonymous to permanent
- Storage costs: Anonymous users accumulate
When to Use
- Try-before-you-buy experiences
- Guest checkout in e-commerce
- Games or apps with progressive engagement
Multi-Factor Authentication (MFA)
Additional security layer beyond primary authentication.
Supported Factors
- TOTP: Time-based codes (Authenticator apps)
- SMS: Text message codes (less secure)
How MFA Works
1. User logs in with primary method
2. If MFA enabled, server challenges for second factor
3. User provides code from authenticator app
4. Server validates, completes authentication
Advantages
- Enhanced security: Second factor required
- Compliance: Required by some regulations
- User confidence: Shows security commitment
Considerations
- Added friction: Extra step every login
- Recovery complexity: Lost device = locked out
- User education: Some users unfamiliar
Choosing Authentication Methods
Consumer Apps
Start with:
- Email/password or Magic Links
- Google OAuth (highest conversion)
- Apple Sign-In (required for iOS)
Developer Tools
Start with:
- GitHub OAuth (expected by developers)
- Email/password as fallback
Enterprise B2B
Start with:
- SSO/SAML for enterprise customers
- Email/password for smaller customers
Mobile Apps
Start with:
- Phone/SMS (native feel)
- Apple + Google OAuth
- Email as fallback
Linking Multiple Providers
Users may want to sign in with different methods:
Same Email Scenario
Day 1: User signs up with email@example.com (password)
Day 2: User clicks "Sign in with Google" (same email)
Options:
1. Link accounts automatically (same email = same user)
2. Require explicit linking
3. Create separate accounts (confusing!)
Supabase can be configured to handle this automatically by linking identities with matching emails.
Multiple Identities
-- User can have multiple identities
auth.users
├── id: uuid-123
├── email: alice@example.com
└── identities:
├── { provider: 'email', ... }
└── { provider: 'google', ... }
Key Takeaways
- Match method to audience: Developers expect GitHub, consumers expect Google
- Offer fallbacks: OAuth providers can fail
- Magic links reduce friction: No passwords to manage
- MFA for sensitive apps: Finance, healthcare, enterprise
- SSO for enterprise sales: Often a hard requirement
- Anonymous for conversion: Let users try before committing
Next Steps
Now that you understand authentication methods, we'll explore JWT tokens—the mechanism that carries authentication state in every request.
The best authentication method is the one your users will actually use. Optimize for conversion while maintaining appropriate security for your use case.