Providers
Configures and manages authentication providers for Better Auth
Category: development Source: better-auth/skillsWhat Is This?
Overview
Better Auth is a modern authentication library for JavaScript and TypeScript applications that offers a flexible provider-based architecture. Authentication providers in Better Auth allow developers to integrate multiple identity sources into a single, unified authentication system. Whether you need social logins, credential-based authentication, or enterprise identity solutions, Better Auth providers give you a structured way to handle all of these within one consistent API.
The provider system in Better Auth is designed to be modular and composable. Each provider handles a specific authentication method, and you can combine multiple providers in a single application without conflicts or redundant configuration. This approach reduces boilerplate code and keeps authentication logic centralized and maintainable.
Better Auth providers also support TypeScript natively, offering full type safety across your authentication flows. This makes it easier to catch configuration errors at compile time and reduces runtime issues in production environments.
Who Should Use This
- Full-stack developers building web applications that require multiple authentication methods
- Backend engineers integrating third-party identity providers such as Google, GitHub, or Discord
- Teams migrating from legacy authentication systems who need a structured replacement
- Developers building SaaS products that require social login and credential-based authentication together
- TypeScript developers who want type-safe authentication configuration
- Security-focused engineers who need fine-grained control over authentication flows
Why Use It?
Problems It Solves
- Managing multiple authentication methods across different libraries creates inconsistency and increases maintenance overhead. Better Auth providers unify all methods under one API.
- Setting up OAuth flows manually requires significant boilerplate and error-prone token handling. Providers abstract this complexity away.
- Credential-based and social authentication often require separate implementations. Better Auth allows both to coexist cleanly.
- Type errors in authentication configuration are hard to catch without native TypeScript support. Better Auth providers are fully typed.
- Scaling authentication across multiple environments requires flexible configuration. Better Auth providers support environment-specific settings natively.
Core Highlights
- Modular provider architecture that supports mixing and matching authentication methods
- Built-in support for popular OAuth providers including Google, GitHub, Discord, and more
- Full TypeScript support with strict type inference for provider configuration
- Credential provider for username and password authentication with hashing utilities
- Session management integrated directly into the provider system
- Extensible plugin system for custom provider logic
- Consistent error handling across all provider types
- Works with popular frameworks including Next.js, Nuxt, and SvelteKit
How to Use It?
Basic Usage
Install Better Auth and configure providers in your authentication setup file.
npm install better-auth
import { betterAuth } from "better-auth";
import { github, google } from "better-auth/providers";
export const auth = betterAuth({
providers: [
github({
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET,
}),
google({
clientId: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_CLIENT_SECRET,
}),
],
});
Specific Scenarios
Adding credential-based authentication alongside social providers:
import { betterAuth } from "better-auth";
import { credentials, github } from "better-auth/providers";
export const auth = betterAuth({
providers: [
credentials({
authorize: async (email, password) => {
const user = await getUserByEmail(email);
if (!user || !verifyPassword(password, user.hash)) return null;
return user;
},
}),
github({
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET,
}),
],
});
Restricting allowed email domains for a provider:
google({
clientId: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_CLIENT_SECRET,
allowedDomains: ["yourcompany.com"],
}),
Real-World Examples
- A SaaS application uses GitHub and Google providers for developer sign-in while keeping a credentials provider for admin accounts.
- An internal tool restricts Google login to a specific corporate domain using the
allowedDomainsoption. - A marketplace platform combines Discord OAuth for community members with email and password login for vendors.
When to Use It?
Use Cases
- Applications requiring social login with multiple OAuth providers
- Internal tools that need corporate SSO integration
- Platforms combining public and private authentication methods
- Projects where TypeScript type safety in authentication is a priority
- Applications needing centralized session management across providers
- Multi-tenant SaaS products with per-tenant authentication rules
- Rapid prototyping where pre-built providers reduce setup time
Important Notes
Requirements
- Node.js version 18 or higher is required
- A supported database adapter must be configured for session persistence
- OAuth providers require registered applications with valid redirect URIs
Usage Recommendations
Do:
- Store all secrets in environment variables and never commit them to version control
- Validate provider configuration at application startup
- Use the TypeScript types provided to catch configuration errors early
- Test each provider in a staging environment before deploying to production
- Keep provider versions updated to receive security patches
Do not:
- Hardcode client secrets directly in provider configuration objects
- Mix Better Auth session handling with a separate session library
- Skip redirect URI validation when registering OAuth applications