Auth providers for SaaS founders

Founders often use auth as one word, but there are three separate jobs inside it. Authentication proves the user is who they say they are. Session management keeps that user signed in across requests. Authorization decides what the signed-in user is allowed to see or change.

A simple SaaS product still needs all three. A user signs in with email, Google, GitHub, or Microsoft. The app stores a session. Then the backend decides whether that user can open a project, invite a teammate, access billing, or read a private record.

This is why auth is rarely just a login screen. It touches product onboarding, database security, team permissions, auditability, customer trust, and the polish of your sign-in flow.

Supabase Auth is the cleanest default when your app already uses Supabase for Postgres, storage, APIs, and Row Level Security. It supports email auth and OAuth providers such as Google, GitHub, Microsoft, Apple, and other common identity providers, while keeping the authenticated user tied directly to your database security model.

Clerk is a polished hosted auth platform with excellent React and Next.js ergonomics, prebuilt UI, organizations, user profiles, passkeys, and developer experience. It is a strong choice when auth UX and frontend speed matter more than keeping auth inside your database provider.

Better Auth is a free, open-source TypeScript auth framework. It suits founders who want more ownership and code-level control, but it also means you own more implementation detail, hosting, upgrades, security review, and operational discipline.

Kinde is an auth, billing, feature flag, and access management platform from Australian founders. It is attractive when you want a generous free tier, custom domain support, and product-led SaaS features beyond basic login.

WorkOS is strongest when you are building toward enterprise customers. AuthKit user management is free at a large scale, while WorkOS also gives you enterprise SSO, directory sync, audit logs, Admin Portal, and custom domains as separate commercial building blocks.

If you are building a standard indie SaaS on Vercel, Next.js, and Supabase, start with Supabase Auth unless you have a specific reason not to. The reason is not that Supabase has the flashiest auth UI. The reason is that the auth identity, database, API layer, and Row Level Security model all live in the same operating system.

That matters once you move past login. With Supabase, the same user identity can protect Postgres rows, scope API calls, support server-side checks, and connect cleanly to your project data. For a solo founder, fewer moving parts usually beats a more beautiful standalone auth dashboard.

The hosted providers are still valid. Choose Clerk when you want the fastest polished auth frontend. Choose Kinde when its built-in billing, flags, and generous free tier match your product. Choose WorkOS when enterprise SSO and auditability are part of the plan. Choose Better Auth when you want open-source control and are willing to own the operational work.

Pricing changes often, so treat this as a snapshot from the public pricing pages checked on May 30, 2026. For 1,000 monthly active users, the base auth cost is usually less important than the plan features, custom domain cost, organizations, enterprise SSO, and whether the provider also charges for billing, SMS, machine-to-machine tokens, or add-ons.

Supabase Auth can handle 1,000 users on the Free plan for simple projects, but most production SaaS apps will choose Supabase Pro at $25 per month for the broader backend features and production posture. A custom domain is a separate $10 per month add-on, so a professional branded Supabase Auth setup is commonly $35 per month before usage add-ons.

Clerk currently advertises a free tier that covers far more than 1,000 users, so the base auth cost for 1,000 users can be $0. You should still check whether the features you need, such as custom domain, organizations, billing features, or higher limits, require a paid plan or add-on.

Better Auth is free and open source, so the software cost for 1,000 users is $0. The real cost is your database, hosting, transactional email, monitoring, rate limiting, maintenance time, and security responsibility.

Kinde includes 10,500 monthly active users on the Free plan, including social login and custom domain support, so 1,000 users can be $0 on the base plan. Paid plans begin at $25 per month when you need Pro features, uncapped usage, or more advanced SaaS controls.

WorkOS User Management is free up to 1 million monthly active users, so 1,000 users can be $0 for AuthKit user management. WorkOS becomes expensive when you add enterprise pieces: SSO connections are priced separately, and the custom domain product is listed at $99 per month.

A custom auth domain makes your sign-in flow feel more professional because users see your domain rather than a provider-owned URL during parts of the authentication process. This is most noticeable with OAuth, magic links, and hosted auth pages.

Supabase custom domains are useful but not free. Supabase lists custom domains as a flat $10 per month add-on, and Supabase Auth will use the custom domain once it is activated. For a paid SaaS, that is usually worth it because the login flow feels closer to the rest of your brand.

Kinde is unusually generous here because its Free plan includes using your own custom domain. WorkOS lists custom domains as a paid service, with the pricing page showing $99 per month. Clerk and Better Auth need a closer plan-specific check: Clerk exposes custom domain support in its pricing matrix, while Better Auth depends on where and how you host your own auth endpoints.

When you connect Google login through Supabase Auth, you still need to create and configure a Google Cloud project. Ideally, that Google Cloud account should belong to the company rather than a personal Gmail account, because OAuth consent screens, ownership, billing, and future access reviews become business infrastructure.

The basic setup is to create a Google OAuth client, add your app URL as an authorized JavaScript origin, add the Supabase callback URL as an authorized redirect URI, then copy the Client ID and Client Secret back into Supabase. For local development, Supabase also supports putting the Google client secret in an environment variable and referencing it from the local Supabase config.

For production, keep the Google Client Secret out of source code. Store provider secrets in your deployment or secrets system, document which Google Cloud project owns them, and include the setup in your launch checklist. The same habits apply when you add GitHub, Microsoft, or any other social provider.

Auth setup almost always creates environment variables. A Supabase app typically needs values such as NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY, while provider secrets such as a Google Client Secret must stay server-side or in provider configuration rather than leaking into browser code.

The practical mistake is treating auth credentials as one-off setup. They should be part of your environment variables and secrets management process: named clearly, separated by local, preview, and production environments, and rotated when ownership changes or a leak is suspected.

If you are working through this in Trackk, cross-link the auth setup step to the environment variables and secrets management guide, then add provider-specific tasks for Google Cloud, callback URLs, production redirect URLs, custom domain activation, and final login testing.

Use Supabase Auth when Supabase is already your backend and you want database-backed authorization with the fewest moving pieces. Use Clerk when frontend auth polish and speed are the main priority. Use Kinde when its free tier, custom domain support, billing, and feature management line up with your product model.

Use WorkOS when enterprise readiness is not a future fantasy but part of your go-to-market plan. Use Better Auth when you prefer open-source control and have the judgment to operate auth as security-critical infrastructure.

For most early Vercel and Supabase SaaS projects, the conservative answer is the right one: start with Supabase Auth, add Google and GitHub only when you need them, pay for the custom domain when the product is customer-facing, and keep the provider credentials documented in your environment setup.