Buyers often compare Auth.js, Clerk, and custom cookie JWT kits as if they were the same product. They are not. Hosted identity is faster to launch; owned identity is easier to audit and revoke precisely.
Decision shortcuts
- Need device-level revoke and own the hashes: prefer cookie JWT + server sessions.
- Need social login fast and accept vendor lock: Auth.js or Clerk-style kits.
- Need opaque sessions only: classic session-id cookie with Redis or Postgres.
- Need enterprise SSO soon: confirm SAML/OIDC is real, not a roadmap bullet.
What "production auth" means on a product page
- Signup, login, logout, and password reset paths.
- httpOnly cookies (or a documented bearer strategy for APIs).
- Lockout or rate limiting story for brute force.
- Email verification if the product depends on working inboxes.
Run Twenty's free auth architecture picker before you buy. Then browse the auth-systems category with your stack filter applied.
Cookie JWT + refresh (why many kits use it)
Short-lived access tokens in httpOnly cookies plus a refresh row you can delete give you revoke without waiting for JWT expiry. Middleware can validate the access cookie quickly; refresh stays a deliberate server action. Twenty itself uses this pattern - not as dogma, as a concrete reference.
Hosted auth tradeoffs
Clerk and similar vendors shrink launch time. You trade control of session storage, pricing at scale, and sometimes compliance questionnaires. If your buyer is enterprise security, ask where refresh tokens live before you commit.
What to verify on the product page
- Setup instructions list JWT_SECRET / SESSION_SECRET / OAuth client IDs by name.
- There is a first login path documented for local and production.
- Middleware or layout protection is shown, not only a login form.
- Password reset does not leak whether an email exists (or documents the choice).
Integration pitfalls
- Mounting auth routes under a path the kit did not expect.
- Forgetting SameSite / secure cookie flags on HTTPS previews.
- Mixing client-readable tokens with httpOnly designs.
- Skipping email provider setup then blaming the kit for "broken auth."
If you also need Stripe, prefer kits that keep auth and billing as separate tables so you can upgrade either side later.