Why this choice matters more than your landing page
Auth is infrastructure you feel every week after launch. It decides where password hashes live, whether you can kill a stolen laptop session in one click, and whether App Router middleware can trust a cookie without waking the database on every navigation.
Teams usually land on one of four shapes. None of them are "wrong." The expensive mistake is picking hosted OAuth because a Twitter thread said so, then discovering six months later that your compliance questionnaire asks where refresh tokens are stored - and the honest answer is "inside a vendor we cannot audit."
Twenty itself ships cookie JWT + refresh sessions: a short-lived access token in an httpOnly cookie, plus a server-side sessions table for rotation and revocation. That is not a moral claim that everyone should copy us. It is a concrete reference point for the rest of this article.
Before you pick a pattern, write down the three auth events that would ruin your week: a stolen laptop, a leaked refresh token in a support screenshot, an enterprise buyer asking where password hashes live, or a mobile client that needs offline access. Those failure modes filter the options faster than any framework fashion.
Cookie JWT + refresh sessions
In this model the browser never holds a bearer token in `localStorage`. The access JWT expires quickly - often around fifteen minutes. A longer-lived refresh credential rotates on use and is stored as a row you can delete. Delete the row, and that device is done, even if the old access cookie has a few minutes left.
This pattern fits first-party web SaaS especially well. Server Components can read the cookie, Route Handlers can rotate refresh tokens, and you keep password hashes, lockout counters, and email-verification state in your own Postgres.
The work you still own is real: password reset flows, CSRF posture for cookie-authenticated mutations (SameSite plus origin checks), MFA if you need it, and careful handling of concurrent refresh. You are trading vendor speed for control.
One subtle win shows up in incident response. When a user says "someone is in my account," you can list sessions by device label, revoke one row, and leave every other device alone. That story is hard to tell when identity is entirely inside a black-box vendor session.
Choose this when you care about owning identity data, need device-level revoke, and expect auth to stay a product risk for years.
Opaque server sessions
Here the cookie is just a random session id. Everything meaningful lives in Postgres or Redis. Logout everywhere is a delete query. The mental model is simple, which is why so many classic Rails and Laravel apps still look like this.
The tradeoff shows up at the edges. Middleware that wants to know "who is this?" either hits the session store or a cache in front of it. Mobile clients almost always need a separate token endpoint anyway, so you may end up inventing JWT-like APIs later while still calling the core pattern "sessions."
Opaque sessions also make horizontal scaling a caching problem. Sticky sessions or a shared Redis keep things honest. If your kit assumes a single Node process and you suddenly run on serverless, cold starts plus session lookups need a plan.
Choose this when your product is mostly a browser admin tool, traffic is modest, and you want the simplest possible revocation story.
OAuth-first (hosted auth)
Clerk, Auth0, Supabase Auth, and similar products optimize for "login UI this week." Social providers, hosted components, and mobile SDKs arrive bundled. For a solo founder validating demand, that speed is often the correct business decision.
The cost arrives later. Session semantics follow the vendor. Migrating off is a project, not a config change. If a buyer asks where the password hash lives, you may not have one - and that can be fine until it is not.
Hosted auth is also a product dependency. Pricing tiers, outages, and feature gates become part of your roadmap. That is acceptable when auth is not your differentiator. It is painful when auth is your differentiator - marketplaces, developer tools, and B2B products with unusual invite flows often outgrow the happy path.
Choose this when time-to-login dominates, you are comfortable with vendor pricing and data residency, and you do not expect to need exotic session rules soon.
Hybrid: social identity, your sessions
Google or GitHub proves who the human is. After the OAuth callback, you issue your own httpOnly access cookie and refresh session. Buyers get the "Sign in with GitHub" button without fully outsourcing session lifetime.
You still implement account linking carefully: the same email arriving from two providers should not silently create two users. Email/password, if offered alongside social, needs a deliberate merge story.
Hybrid is also how many kits on Twenty behave in practice: optional OAuth providers on top of a first-party session layer. Read the setup docs for callback URLs and whether email/password remains first-class.
Choose this when social login is table stakes, but revoke and audit still need to live in your database.
A decision rule you can actually use
Start from the failure you refuse to accept.
If the failure is "we cannot prove where credentials live," prefer cookie JWT or opaque sessions. If the failure is "we miss the launch window," prefer OAuth-first. If the failure is "we cannot kill a compromised device tonight," prefer any pattern with a server-side session row you control - cookie JWT with refresh sessions, or opaque sessions.
App shape matters too. Pure web SaaS loves cookies. Web plus mobile wants a clear token story either way. B2B products that might need SAML later should avoid painting themselves into a hosted-auth corner unless the vendor already sells that path at a price you accept.
Write the choice down in the README of your own product. Future you will thank present you when a contractor asks why refresh tokens exist.
How this maps to buying a kit
When you browse auth kits on Twenty, read the setup instructions for cookie names, refresh rotation, and whether OAuth is optional glue or the whole product. A kit that assumes Clerk will not drop cleanly onto a custom JWT codebase without a rewrite.
Look for evidence of lockout, email verification, and session listing in the feature bullets. Marketing copy that only says "auth included" is not enough - ask what happens on password reset and on logout-all-devices.
If you want a structured recommendation from a few questions, use the free auth architecture picker. It scores the four patterns above the way production teams usually argue about them - control, speed, revoke, and social-login weight - then points you back to matching marketplace categories.
