Postgres has become the default database for a lot of new apps, but it only stores who can do what once you tell it. Authentication (who a user is) and authorization (what they are allowed to do) still sit on you. The good news is that you do not have to build either from scratch.
This post groups the open-source options by how much of the work they take off your hands, from full platforms down to the bare JWT-to-RLS pattern, with a short "best for" note on each so you can find the one that matches your setup.
1. Platforms (Postgres + Auth bundled)
These give you Postgres, authentication, and APIs in one package. The draw here is that RLS (Row Level Security) works out of the box, so you are not wiring claims into policies by hand.
🔹 Supabase Auth
Supabase Auth
- Features: Email/password, magic links, OAuth, phone, Web3 logins.
- Integration: Deep RLS support, with
auth.uid()andauth.jwt()usable directly in policies. - Third-party support: You can trust IdPs like Clerk, Firebase Auth, Cognito, or WorkOS, but only if they issue asymmetric JWTs. Key rotation can lag around 30 minutes, and Supabase Auth itself can't be disabled, so it is always part of the picture.
- Best for: Startups and teams that want the fastest path to a secure Postgres app without standing up auth themselves.
🔹 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 the whole stack to stay open source.
2. Libraries (you own the server)
These plug into a backend you already run, store users in Postgres, and issue JWTs. More wiring than a platform, but you keep control of every piece.
🔹 Auth.js
- Features: 50+ OAuth providers, session handling, JWT support.
- Integration: Postgres adapter for users and sessions.
- Best for: Apps with a custom backend, especially Next.js or full-stack JS where it already feels native.
🔹 Better Auth
- Features: TypeScript-first, with multi-tenancy, 2FA, and org management built in.
- Integration: Native Postgres support via Kysely or Drizzle, plus 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 only. Worth knowing for what it taught the ecosystem, but not a starting point for anything new.
3. Identity Servers (standalone IdP)
These run as separate services and act as the source of truth for identity, issuing JWTs that your apps consume. More to operate, but the right shape once identity has to be shared across services.
🔹 Ory Kratos
- Features: Registration, recovery, passwordless login, customizable flows.
- Integration: Uses Postgres as the identity store and issues JWTs that RLS can read.
- 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 that need enterprise SSO and federation. It is the heaviest option here, and that is the trade-off for the breadth.
🔹 ZITADEL
- Features: Modern IdP with org/project/role management.
- Integration: Postgres or Cockroach backend; OIDC flows into Postgres RLS.
- Best for: Cloud-native teams who want an OSS alternative to the commercial IdPs without taking on Keycloak's footprint.
4. Other OSS Options
🔹 SuperTokens
- Features: Recipes for email/password, social login, passwordless, and session management.
- Integration: Native Postgres support, cloud or self-host.
- Best for: Developers who want prebuilt flows to drop in but would rather stay OSS-first.
5. Postgres-Native Pattern (minimalist)
You can also skip a dedicated auth system entirely:
- 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 want the database itself to drive access.
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
There is no single best pick here, only the one that fits your stack and how much you want to operate:
- 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
Whichever one you land on, the underlying principle stays the same: JWT claims flow into Postgres RLS, which makes the database itself the final gatekeeper. If you trust nothing else in the chain, that last line of defense is the one worth getting right.