get-convex
Issue Title: Feature Request: Add Support for Additional Authentication Providers (e.g., Apple, Microsoft, Email/Password)
Problem Description Currently, the authentication flow in Chef is limited to Google and GitHub OAuth providers. While these are popular choices, many applications require a broader range of sign-in options to cater to their diverse user bases (e.g., enterprise users with Microsoft accounts, iOS users expecting Sign in with Apple, or users who prefer a classic email/password login).
The lack of alternative providers can be a barrier to adoption for developers evaluating Convex and Chef for their projects.
Proposed Solution Extend the authentication system to be more flexible and modular, allowing for easy integration of additional OAuth providers and other methods like Email/Password (with magic links).
Suggested high-priority providers to add:
Sign in with Apple: Crucial for App Store compliance on iOS apps.
Microsoft Entra ID (Azure AD): Important for enterprise/business applications.
Email/Password (with Magic Links): A fundamental and expected option for many users.
The ideal implementation would follow a pattern similar to popular auth libraries (like next-auth or auth.js), where adding a new provider is a matter of supplying credentials and a configuration object.
Example of Desired Usage In the convex/auth.config.js file, developers could configure new providers in a simple list:
javascript // convex/auth.config.js const authConfig = { providers: [ { id: "google", name: "Google", type: "oauth", // ... existing config }, { id: "github", name: "GitHub", type: "oauth", // ... existing config }, // NEW: Add a Microsoft provider { id: "microsoft", name: "Microsoft", type: "oauth", issuer: "https://login.microsoftonline.com/{tenant}/v2.0", clientId: process.env.MICROSOFT_CLIENT_ID, clientSecret: process.env.MICROSOFT_CLIENT_SECRET, }, // NEW: Add an Email provider { id: "email", name: "Email", type: "email", // Handles sending the magic link sendVerificationRequest: ({ identifier: email, url }) => { // ... logic to send email }, }, ], }; The UI components (like the sign-in button) would automatically adapt to the configured providers.
Alternatives Considered Manual Implementation: Developers could try to implement their own auth layer outside of Chef, but this defeats the purpose of using a starter kit—it's complex, error-prone, and would not be integrated with the existing user model and Convex auth.
Forking and Modifying: Forking the repo to add a single provider is unsustainable and makes it impossible to receive upstream updates.
Additional Context This enhancement would make Chef an even more compelling and versatile starter kit for the Convex ecosystem.
The auth.js project (https://authjs.dev/) is a fantastic reference for a well-designed, provider-agnostic authentication API for Next.js.
Why this issue is effective: Clear, Descriptive Title: It immediately tells maintainers what the request is about.
