SvelteKit Authentication in 2026: Better Auth, Lucia, Auth.js & Supabase Auth

A practical decision guide for SvelteKit authentication in 2026. Better Auth, Lucia (deprecated), Auth.js, and Supabase Auth — what each does well, what it doesn't, and when to pick which.

Authentication in the SvelteKit ecosystem changed significantly in 2025. Lucia — once the default recommendation — was deprecated. Better Auth exploded in popularity. Auth.js stabilized its SvelteKit adapter. And Supabase Auth continued being the “just use the platform” option.

If you’re starting a new SvelteKit project in 2026, here’s the landscape as it actually is — not as Twitter hype would have you believe.

The state of play

SolutionTypeStatusGitHub StarsWeekly DownloadsSvelteKit Support
Better AuthSelf-hosted libraryActive, rapidly growing~25,000+~600K+Official adapter
Lucia v3Self-hosted libraryDeprecated (learning resource)~9,000DecliningWas the standard
Auth.jsSelf-hosted libraryActive, stable~25,000+~500K+Official @auth/sveltekit
Supabase AuthManaged serviceActiveN/A (platform)N/AOfficial SSR package

Better Auth

Better Auth is the successor story. After Lucia’s deprecation, the Svelte/Kit community needed something with the same “own your auth” philosophy but with more features and active development. Better Auth filled that gap and then some.

What it does:

  • Email/password, OAuth (20+ providers), magic links, passkeys, WebAuthn
  • Two-factor authentication (TOTP, SMS, email)
  • Session management with configurable strategies
  • Plugin system: organizations, API keys, admin panel, rate limiting
  • Database-agnostic via adapters (Drizzle, Prisma, Kysely, etc.)
  • SvelteKit-native with sveltekitCookies plugin for proper cookie handling in server actions

What’s good:

  • The plugin architecture is genuinely excellent. Need multi-tenancy? Add the organizations plugin. Need API keys? There’s a plugin. Need an admin panel? Plugin. You compose what you need.
  • TypeScript-first with end-to-end type safety
  • Active development — multiple releases per month
  • The SvelteKit integration is first-class, not an afterthought
  • Self-hosted: your data, your database, your rules
  • Official svelte add better-auth via Svelte CLI

What’s not:

  • Newer project means less battle-testing in production at scale (though adoption is growing fast)
  • Documentation is good but still maturing — some edge cases are under-documented
  • The plugin system means you need to evaluate what to include upfront. More decisions than a batteries-included solution.
  • If you just need Google OAuth and nothing else, Better Auth might be overengineered for your needs

SvelteKit setup complexity: Medium. You configure the auth instance, set up a server handler, and use the sveltekitCookies plugin. Maybe 30 minutes for a basic setup with email + OAuth.

Which starters use Better Auth

  • OpenSaaS Svelte — free, with Prisma + Stripe + Postgres
  • PayKit — $49, minimal Stripe Checkout integration

Lucia (Deprecated)

Let’s be direct: Lucia v3 was deprecated in early 2025. The npm package still works. The code isn’t broken. But there are no new features, no new adapters, and bug fixes are minimal.

Why it was deprecated: The creator concluded that the database adapter model was too inflexible for a low-level auth library. Rather than fighting the architecture, Lucia pivoted to being a learning resource — teaching developers how sessions actually work so they can implement auth themselves.

What it still does (if you have it):

  • Session-based authentication
  • Multiple database adapters (though no new ones)
  • Clean, minimal API

Should you use it in a new project? No. Here’s why:

  • No new security patches beyond critical fixes
  • Adapters won’t be updated for new database versions
  • The ecosystem (tutorials, examples, community help) is drying up
  • You’ll need to migrate eventually — might as well start with something active

If you already have Lucia in production: Don’t panic. It works. But plan your migration. Better Auth and “roll your own sessions” (using Lucia’s educational resources) are the two recommended paths.

Which starters still use Lucia

These starters still function correctly, but you should factor in the eventual auth migration cost.


Auth.js (@auth/sveltekit)

Auth.js (formerly NextAuth) expanded beyond Next.js to support SvelteKit, Express, and other frameworks. The SvelteKit adapter is officially maintained and stable.

What it does:

  • OAuth with 50+ providers out of the box
  • JWT or database sessions
  • Email/magic link sign-in
  • Credentials provider (email + password)
  • Database adapters for most ORMs

What’s good:

  • Massive provider list — if you need “Sign in with X” for an obscure OAuth provider, Auth.js probably supports it
  • Mature project with years of production use (as NextAuth)
  • JWT mode means no database needed for simple use cases
  • The SvelteKit integration adds auth() to event.locals — clean, idiomatic
  • Large community, extensive documentation, many examples

What’s not:

  • Auth.js was designed for Next.js first. The SvelteKit adapter works, but you’ll occasionally encounter documentation or examples that assume Next.js patterns.
  • Customization beyond the happy path can be frustrating. Callbacks, events, and adapter hooks have a learning curve.
  • The credentials provider (email + password) is intentionally limited — Auth.js wants you to use OAuth or magic links. If you need traditional password auth with password reset flows, you’ll fight it.
  • Session management is opaque. Debugging “why isn’t my session available” issues requires understanding Auth.js internals.

SvelteKit setup complexity: Low-medium. Add @auth/sveltekit, configure providers in hooks.server.ts, access sessions via event.locals.auth(). Basic OAuth works in 15 minutes. Custom flows take longer.

Which starters use Auth.js

None in our current directory use Auth.js directly, though SvelterApp (mentioned in our admin dashboard roundup) does.


Supabase Auth

Supabase Auth is the “platform” option. You’re not self-hosting auth — Supabase manages the auth service, and you interact with it via their SDK.

What it does:

  • Email/password, magic links, phone/SMS OTP
  • OAuth providers (Google, GitHub, Apple, etc.)
  • Row Level Security (RLS) integration — auth directly controls database access
  • Anonymous sign-in
  • Multi-factor authentication
  • 50,000 monthly active users on the free tier

What’s good:

  • Zero auth infrastructure to manage. No session tables, no token rotation logic, no password hashing decisions.
  • RLS integration is powerful. Your database policies reference the authenticated user directly. Auth and authorization become one thing.
  • The @supabase/ssr package handles cookies and refresh-token rotation for SvelteKit properly
  • 50K MAU free tier is generous — most projects won’t outgrow it quickly
  • Dashboard UI for managing users, viewing sessions, configuring providers

What’s not:

  • Vendor lock-in. Your auth is tied to Supabase. Moving away means migrating users, sessions, and password hashes.
  • Customization is limited to what Supabase exposes. Need a custom claim in your JWT? Need a non-standard session flow? You might be stuck.
  • Latency. Auth calls go to Supabase’s servers. For most apps this is fine (sub-100ms), but it’s not the same as a local database lookup.
  • The SSR setup for SvelteKit — while documented — has specific patterns you must follow. Get it wrong and you’ll have hydration mismatches or stale sessions.

SvelteKit setup complexity: Medium. You need to create Supabase clients for both server and browser contexts, handle the auth callback route, and set up cookie-based sessions correctly. The docs are clear but there are several files to touch.

Which starters use Supabase Auth

  • SvelteSaaS — uses Supabase as the database (Lucia handles auth separately)
  • SvelteStack Pro — Supabase for hosting/database
  • SvelteFire Kit — uses Firebase Auth (similar managed approach, different platform)

Decision tree

Here’s the practical version. Start from what you need:

“I need full control and I’m building a serious product”

Pick Better Auth.

You get self-hosted auth with a plugin system that scales from basic email/password to enterprise multi-tenancy. You own the data. You can switch databases. You can add features incrementally.

Start with: OpenSaaS Svelte (free, Better Auth + Prisma + Stripe)

“I need OAuth with many providers and minimal setup”

Pick Auth.js.

50+ OAuth providers out of the box, JWT sessions mean no database needed for simple cases, and the SvelteKit adapter is mature. If your app is “sign in with Google/GitHub and go,” Auth.js gets you there fastest.

”I’m already using Supabase for my database”

Pick Supabase Auth.

If Supabase is your database, using their auth means RLS policies work automatically, you don’t run a separate auth service, and the free tier is generous. Don’t introduce a separate auth system when your platform already provides one.

”I need the absolute minimum — just sessions”

Roll your own.

Lucia’s documentation (now a learning resource) teaches you how sessions work: generate a token, store it in a cookie, validate it on each request, refresh before expiry. For simple apps with one login method, 50 lines of code beats any library.

”I’m building an MVP and might pivot”

Pick Better Auth or Supabase Auth depending on your database choice.

If you’re using Supabase: use their auth. If you’re using Postgres/SQLite/anything else: use Better Auth. Both are actively maintained and won’t leave you stranded.

”I already have Lucia and need to migrate”

Migrate to Better Auth.

The philosophy is closest (self-hosted, database-backed sessions, TypeScript-first), and Better Auth’s documentation includes migration guidance. The concepts map 1:1 in most cases.


Feature comparison matrix

FeatureBetter AuthAuth.jsSupabase AuthDIY (Lucia-style)
Email/passwordYesLimitedYesYou build it
OAuth providers20+50+~15You integrate
Passkeys/WebAuthnYes (plugin)ExperimentalNoYou implement
2FA/MFAYes (plugin)NoYesYou implement
Magic linksYesYesYesYou build it
API keysYes (plugin)NoNoYou build it
Organizations/teamsYes (plugin)NoNoYou build it
Admin panelYes (plugin)NoDashboard UINo
RLS integrationNoNoYesNo
Self-hostedYesYesNoYes
No database neededNoYes (JWT mode)N/ANo
SvelteKit-nativeYesYesYesYes

What I’d pick for a new project today

If I’m building a SaaS with SvelteKit in May 2026: Better Auth. The plugin system means I can start minimal and add features (2FA, organizations, API keys) without switching libraries. It’s self-hosted so I own my data. The SvelteKit integration is clean. And the momentum is undeniable — 25K+ stars and 600K+ weekly downloads in under two years.

If I’m building a simple app that just needs “sign in with Google”: Auth.js. It’s overkill-proof for simple OAuth flows.

If I’m all-in on Supabase already: Supabase Auth. Don’t fight the platform.

If I’m building something tiny and educational: Roll my own sessions. It’s 50 lines of code and you’ll actually understand what’s happening.

The one thing I wouldn’t do: start a new project with Lucia. Respect the library for what it taught us, but it’s time to move on.


Further reading

Get new starters in your inbox

Monthly picks, reviews, and the occasional deep-dive.

No spam. Unsubscribe anytime.

Need pre-built UI components for your SvelteKit project? Check out svelteblocks.com →