#what is recommened for auth?

15 messages · Page 1 of 1 (latest)

trail hazel
#

Im wondering if convex recommends using convex auth or if they just recommend using something like clerk?

flat spireBOT
#

Hi @trail hazel. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Convex’s current guidance is:

  • For most production apps, Convex recommends a third‑party auth provider like Clerk, WorkOS AuthKit, or Auth0. These give you more features (MFA, passkeys, spam protection, SSO, etc.) and are the “most comprehensive authentication solutions.” [Auth overview; Clerk docs]

  • Convex Auth is positioned as a quick, built‑in option, but it’s beta/legacy:

    • Official docs: “Convex Auth is in beta… doesn’t provide as many features as third party auth integrations… it’s the quickest way to get auth up and running.” [Auth overview; Convex Auth docs]
    • In Discord, staff explicitly say that because Convex Auth is built on Auth.js (which is effectively deprecated), if you want something “future proof on a new project,” they recommend Better Auth or a service‑backed provider (like Clerk). Convex Auth “is safe to use and fully supported” today, but is considered legacy for new projects. [Discord status]

So:

  • New project, long‑term / production → Prefer Clerk, WorkOS, Auth0, or Better Auth.
  • Prototype / want something simple, all in Convex, React‑only → Convex Auth is fine, just be aware it’s beta and not the “future‑proof” path.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@trail hazel Kapa.ai is still learning and improving, please let me know how I did by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

Sorry @trail hazel, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:

Perhaps try again in 15mins?

trail hazel
#

@flat spire but ive been hearing that theres issues with performance wiht better auth + convex

flat spireBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

You’re right to have noticed this—there are known performance considerations with Better Auth + Convex right now.

From the sources:

  • Better Auth’s HTTP auth endpoints often show ~200ms latency for verification. A Convex engineer explains this is currently because Better Auth DB calls are implemented as multiple Convex functions, not a single transaction, so there’s extra overhead per request.[Better Auth latency]

  • The same engineer notes that:

    • Reducing this by “running the whole thing in a single query/mutation” was explored but has architectural issues with components and config isolation.
    • Some of the overhead is already absorbed by internal query caching, so it’s unclear how much more can realistically be shaved off.[Better Auth latency]

  • Another thread confirms that Better Auth endpoints are “high right now” and that this is a known pain point they’re trying to improve, especially for apps that heavily use Better Auth APIs (e.g. org/admin features).[Authjs & Better Auth]

  • There are experimental features specifically aimed at performance:

So the picture is:

#
  • Yes, Better Auth + Convex has more overhead than Convex Auth in some setups, especially around HTTP auth endpoints and heavy use of auth.api methods.
  • Convex is aware of this and has work in progress / experimental optimizations (JWT caching, static JWKS), but it’s not yet as lean as a minimal, built‑in solution.
  • For many apps it’s “acceptable but not amazing”; for latency‑sensitive or auth‑heavy flows, it can feel slow.

If you’re very sensitive to auth latency right now:

  • Convex Auth or a service like Clerk (with Convex’s Clerk integration) may feel snappier in practice, especially if you’re not leaning heavily on Better Auth’s advanced plugins.
  • If you do choose Better Auth, consider enabling JWT caching and static JWKS from the experimental docs to mitigate some of the overhead.[Experimental JWT caching]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@trail hazel Kapa.ai is still learning and improving, please let me know how I did by reacting below.

trail hazel
#

@flat spire does clerk also have performance issues with convex?

flat spireBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

There’s not much hard, quantitative data in the sources about Clerk+Convex performance, but here’s what is documented:

  • The official Clerk integration is presented as a normal, recommended path; there’s no warning in the docs about systemic performance problems. [Clerk React guide; Under the hood]

  • Under the hood, Convex validates the Clerk JWT on client initialization and when needed; this involves fetching Clerk’s public keys (JWKS) and validating the token. [Under the hood] That’s similar in shape to other OIDC providers.

  • A Discord thread mentions that Convex will validate the JWT every time the client initializes (every reload), which can affect “time to first query,” but this is about JWT auth in general, not Clerk‑specific. [JWT validation on init]

  • Another thread about SSR + TanStack + Clerk notes a delay between Clerk being ready and Convex being authenticated, causing “Not authenticated” errors if queries run too early. The recommended mitigation is to avoid running authenticated queries until auth is ready (e.g. using <Authenticated> or skip in useQuery). This is more about coordination / race conditions than raw backend latency. [TanStack + Clerk SSR; Auth best practices]

#
  • In contrast, there are explicit reports and staff comments about Better Auth having ~200ms HTTP auth endpoint latency and being under active optimization; there’s no equivalent “Clerk is slow” discussion in the provided sources. [Better Auth latency]

So, based on the available information:

  • There’s no explicit evidence in these sources that Clerk+Convex has the same kind of systemic performance issues that Better Auth currently does.
  • The main Clerk‑related issues described are about auth timing/race conditions (especially with SSR), not unusually slow token verification on the Convex side.
  • JWT validation on each client init is expected and can add some overhead, but that’s a general pattern, not Clerk‑specific.

Because the sources don’t include benchmarks or broad “Clerk is slow” reports, I can’t say more than that with confidence.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: