Postgres has become the go-to database for modern apps. But authentication (who a user is) and authorization (what they can do) are just as critical.
In 2025, you have plenty of open-source options. To make it simple, here are the most relevant solutions, grouped by type, with clear "best for" recommendations.
1. Platforms (Postgres + Auth bundled)
These give you Postgres, authentication, and APIs in one package. Ideal if you want RLS (Row Level Security) to work out of the box.
🔹 Supabase Auth
- Features: Email/password, magic links, OAuth, phone, Web3 logins.
- Integration: Deep RLS support (
auth.uid(),auth.jwt()directly usable in policies). - Third-party support: Can trust IdPs like Clerk, Firebase Auth, Cognito, WorkOS, etc. but only if they issue asymmetric JWTs. Key rotation can lag ~30 min. Supabase Auth itself can’t be disabled.
- Best for: Startups and teams that want the fastest path to secure Postgres apps.
🔹 Nhost (Hasura-based)
- Features: Postgres + Hasura GraphQL API + Auth.
- Integration: Auth ties into Hasura permissions, which map back to Postgres RLS.
- Best for: Teams building GraphQL-first apps who want a fully open-source stack.
2. Libraries (you own the server)
These plug into your backend, store users in Postgres, and issue JWTs. You stay in control.
🔹 Auth.js
- Features: 50+ OAuth providers, session handling, JWT support.
- Integration: Postgres adapter for users and sessions.
- Best for: Apps with custom backends, especially Next.js or full-stack JS.
🔹 Better Auth
- Features: TypeScript-first, supports multi-tenancy, 2FA, org management.
- Integration: Native Postgres support with Kysely/Drizzle + schema migration tooling.
- Best for: TypeScript-heavy teams who want modern DX and self-hosted control.
🔹 Lucia (maintenance mode)
- Features: Educational focus, lightweight packages.
- Status: v3 is deprecated, supported only until March 2025.
- Best for: Existing projects. Not recommended for new ones.
3. Identity Servers (standalone IdP)
These are separate services that act as the source of truth for identity. They issue JWTs for your apps.
🔹 Ory Kratos
- Features: Registration, recovery, passwordless login, customizable flows.
- Integration: Uses Postgres as identity store; issues JWTs consumed by RLS.
- Best for: Centralized identity across multiple services.
🔹 Keycloak
- Features: Enterprise-grade IdP with OIDC, SAML, LDAP, and multi-realm/org support.
- Integration: Runs on Postgres and issues JWTs for your apps.
- Best for: Large orgs needing enterprise SSO and federation features.
🔹 ZITADEL
- Features: Modern IdP with org/project/role management.
- Integration: Postgres/Cockroach backend; OIDC → Postgres RLS.
- Best for: Cloud-native teams who want a modern, OSS alternative to commercial IdPs.
4. Other OSS Options
🔹 SuperTokens
- Features: Recipes for email/password, social login, passwordless, session management.
- Integration: Native Postgres support; cloud or self-host.
- Best for: Developers who want prebuilt flows but remain OSS-first.
5. Postgres-Native Pattern (minimalist)
You can also skip heavy auth systems:
- Issue JWTs (from a small service or IdP).
- Validate them at the API edge (PostgREST, Supabase, or a proxy).
- Let RLS enforce access inside Postgres.
Best for: Small-to-mid apps where you want maximum simplicity and DB-driven auth.
Comparison Table
| Solution | Type | Hosting | Postgres Integration | Learning Curve | Best for |
|---|---|---|---|---|---|
| Supabase Auth | Platform (BaaS) | Cloud / Self-host | Native (RLS, JWT helpers) | Low | Startups, all-in-one apps |
| Nhost | Platform (GraphQL) | Cloud / Self-host | Hasura + RLS | Medium | GraphQL-first teams |
| Auth.js | Library | Self-host | Postgres adapter | Medium | Flexible, multi-provider apps |
| Better Auth | Library | Self-host | Native schema + migrations | Medium | TypeScript-first projects |
| Lucia (v3) | Library (deprecated) | Self-host | Postgres adapter | High | Legacy projects only |
| Ory Kratos | Identity server | Self-host | Postgres identity store | High | Multi-app identity |
| Keycloak | Identity server | Self-host | Native Postgres | High | Enterprise SSO |
| ZITADEL | Identity server | Self-host / Cloud | Postgres/Cockroach backend | Medium | Cloud-native IdP |
| SuperTokens | Library / Service | Cloud / Self-host | Native Postgres | Medium | Prebuilt flows |
| Postgres-native (JWT → RLS) | Pattern | Self-host | Direct via RLS claims | Low | Minimalist DB-driven |
Conclusion
- Fastest startup path → Supabase Auth
- GraphQL-first stack → Nhost
- Custom backend → Auth.js or Better Auth
- Enterprise / multi-app identity → Keycloak, Ory Kratos, ZITADEL
- Minimalist & DB-driven → Postgres-native JWT → RLS
- Prebuilt recipes → SuperTokens
No matter which tool you pick, the principle is the same: JWT claims flow into Postgres RLS, making the database itself the final gatekeeper.
