Better Auth is not merely adding login buttons. The current signal is sharper than that: a TypeScript authentication framework with 28,808 GitHub stars, 30 GitHub releases in 90 days, and a beta line that is pushing hard into OAuth, OIDC, protected resources, and MCP auth.

That matters because auth frameworks usually become boring in one of two ways. Either they stabilize into a small session library, or they turn into a hosted dashboard where the application delegates the hard parts. Better Auth is trying a different shape. Its official site says the auth lives inside your app, in code, version controlled, type-safe, and reviewable in pull requests. The recent release notes show the cost of that ambition: lots of protocol details, lots of migration notes, and lots of security-sensitive edge cases getting fixed in public.

What Better Auth says it is

The official site describes Better Auth as the most comprehensive authentication framework for TypeScript. The homepage positions it around auth that lives inside the application, with a composable, plugin-based model, examples for email and password, social providers, two-factor authentication, passkeys, and organization support.

The GitHub repository gives the more engineer-friendly version. It describes Better Auth as a framework-agnostic authentication and authorization framework for TypeScript. The README says it provides features out of the box and a plugin system for advanced use cases such as 2FA and multi-tenant support. The stated pain is also clear: authentication in the TypeScript world is framed as a half-solved problem, especially once an app needs more than basic login.

That positioning is credible because the release stream is not just cosmetic. The release notes are full of database adapter behavior, token replay, OAuth provider semantics, OpenAPI output, cookie cache handling, and TypeScript inference fixes. Those are not marketing-layer features. They are the places auth libraries either earn trust or bleed it.

Better Auth is also open source in the strict sense ToolVitals uses. The payload marks it as OSI-approved OSS under the MIT license, and the GitHub repository excerpt says Better Auth is a free and open source project licensed under MIT. That means it is fair to call Better Auth open source here, not merely source-available or open-core.

There is one nuance. The official site also says users can connect to Better Auth infrastructure for a dashboard, audit logs, security detection, enterprise features, and more. ToolVitals currently lists pricing scope as none, with no hosted pricing tracked. So the correct reading is not that Better Auth has no commercial ambitions. The safer reading is that the tracked open-source project is MIT licensed, while the public site is already pointing toward optional infrastructure around it.

The ToolVitals signal: hot, healthy, and very active

ToolVitals gives Better Auth a hot score of 226.7, a health score of 95, a shipping score of 100, and an overall ToolVitals score of 98. Data confidence is 100. The project has 28,808 GitHub stars in the ToolVitals payload, 30 GitHub releases in the last 90 days, and 15 release events in the last 30 days.

Those are strong numbers. They tell a simple story: Better Auth is not sitting on a stale repository, and the project is not relying on old star momentum alone. A shipping score of 100 paired with 15 release events in 30 days means the maintainers are moving code into tagged releases at a fast pace.

The missing fields matter too. ToolVitals does not have 30-day commit count or active contributor count in this payload. That does not weaken the release signal, but it narrows what can be inferred. We can say Better Auth is releasing frequently. We cannot say from this payload how many people are doing the work, how review load is distributed, or whether activity is concentrated in a few maintainers.

Stars also need discipline. The live GitHub API can move minute by minute, but the ToolVitals number is the source of truth for this post: 28,808 stars. That is large enough to signal serious developer attention, but it is not a proxy for production deployments, paid customers, security posture, or successful upgrades.

Compared with related ToolVitals entries, Better Auth sits in an interesting band. LangChain has 139,897 stars, a hot score of 239.7, and 37 release events in 30 days. Composio is closer by star count, with 28,900 stars, a hot score of 230.4, a shipping score of 94, and 22 release events in 30 days. Better Auth has fewer 30-day release events than both, but it matches the maximum shipping score and lands close to Composio in visible GitHub attention.

PostHog is a useful contrast, although it is open-core and in analytics rather than authentication. ToolVitals records 166 release events in 30 days for PostHog, which makes Better Auth’s 15 look restrained. That is not a negative. Auth libraries do not win by flooding users with churn. For auth, the quality of the fixes matters more than raw release volume.

The stable releases are doing security plumbing

The v1.6 line reads like a project cleaning up the nasty parts of real-world auth. Release v1.6.18 fixed expired session cookie cache behavior, duplicate delete-account callbacks, one-time token reuse under concurrent requests, password reset token reuse, Sign-In with Ethereum nonce reuse, rate-limit races, OTP concurrency issues, SAML assertion replay protection, and OIDC logout behavior for cross-site requests.

That is a dense list. It also points to the right kind of maturity work. Authentication bugs often hide in race conditions, stale cookies, replay windows, and weird provider behavior. The v1.6.18 notes show Better Auth addressing exactly those classes of failure.

Release v1.6.19 continued the same pattern. It added support for pre-binding device codes to a specific user in the device authorization plugin, fixed headerless session checks, fixed cookie cache fallback lookup, surfaced sendVerificationEmail errors to the client, repaired TypeScript declaration output, split large session and account cookies near browser size limits, fixed transaction handling for single-use verification flows, improved OpenAPI output, and stopped logging SCIM user filter values.

Release v1.6.20 was smaller, but still practical. It fixed account-linking logs to route through the configured logger, fixed TypeScript inference errors around inherited APIError properties, capped refresh cookie Max-Age at expiresIn, and improved i18n fallback behavior.

The pattern is clear. The stable releases are not just chasing new plugins. They are sanding down the pieces that break in production: cookies, redirects, transactions, provider quirks, generated types, logging, and replay protection.

For a skeptical buyer or engineering lead, this is useful evidence, not a guarantee. It says the maintainers are finding and fixing the kinds of bugs that appear under load and under hostile conditions. It does not prove your adapter, database, reverse proxy, or framework integration will behave correctly. If Better Auth is on your shortlist, build a test plan around concurrency, token replay, multi-host redirects, cookie size, and migration rollback before you put it on the login path.

The beta line points toward OAuth infrastructure and MCP

The most interesting recent release is v1.7.0-beta.6. Its notes include several breaking changes: wildcard endpoint matching for the captcha plugin, the MCP plugin moving into its own package named @better-auth/mcp, explicit OAuth protected resource modeling replacing validAudiences, dynamic baseURL resolution changes around x-forwarded-host, a Google client ID requirement for One Tap validation, and removal of the deprecated oidcProvider plugin from better-auth/plugins.

That is a lot of migration surface for a beta. It also tells you where the project is going. Better Auth is not treating OAuth as a thin social login wrapper. The release notes talk about protected resources, OAuth provider architecture, DPoP sender-constrained access tokens, Cache-Control: no-store on OAuth credential responses, JWKS-backed asymmetric JWT support for session cookie cache tokens, and MCP auth split into a package built on @better-auth/oauth-provider.

For teams building AI agent infrastructure, that MCP move is the part to watch. MCP tools and servers need boring, correct authorization more than they need another clever demo. Moving MCP auth into its own package can make the boundary clearer, but it also raises the bar for documentation and migration quality. The v1.7.0-beta.6 release notes include schema changes and renamed helpers, which means existing users need to treat the upgrade as a real migration, not a patch bump.

Release v1.7.0-beta.9 pushes deeper into OIDC correctness. It restricts custom ID token claims from overriding protected OIDC and JWT protocol claims such as iss, sub, aud, exp, nonce, auth_time, acr, amr, and azp. It also adds support for confidential Dynamic Client Registration clients to complete authorization-code flows without PKCE when configured, supports the claims.userinfo authorization request parameter, fixes UserInfo endpoint bearer token handling for form-encoded POST bodies, improves handling of unsupported authorization parameters, fixes authorization code replay behavior, and rejects refresh token use across different clients.

That list is dry in the best possible way. It suggests the beta line is being shaped by protocol conformance and security boundaries, not just API ergonomics. The downside is obvious: teams on the beta path should expect breaking changes and careful migrations. The upside is that Better Auth is publicly grinding through the details required for serious OAuth provider work.

What the data does not tell you

ToolVitals can see public activity, releases, stars, license signals, SSL and uptime style signals where available, and other measurable surface area. It cannot see code quality in the deep sense. It cannot prove a fix is complete. It cannot measure how many production users upgraded successfully. It cannot tell you whether the project has enough maintainers for the support load created by 28,808 stars.

It also cannot tell you whether Better Auth is the right abstraction for your architecture. Some teams want auth in application code because it makes behavior reviewable and versioned. Other teams want an external identity provider with enterprise support, compliance paperwork, and a dashboard-first operating model. Better Auth’s website speaks strongly to the first group, while also hinting at infrastructure services around audit logs and threat detection. ToolVitals does not currently verify the maturity, pricing, or support model of that infrastructure.

Release velocity can mislead both ways. Fifteen release events in 30 days can mean energy and responsiveness. It can also mean the surface area is changing quickly. Thirty releases in 90 days is a strong maintenance signal, but auth buyers should read changelogs before upgrading, especially when release notes contain breaking changes, schema migrations, and protocol behavior changes.

For maintainers, the public signal is strong, but the risk is documentation debt. The release notes are unusually detailed, which is good. The next step is making migrations boring for users who are not OAuth specialists. The v1.7 beta notes cover protected resources, MCP package migration, DPoP, Dynamic Client Registration, and OIDC claim restrictions. Those deserve upgrade guides that group changes by user type: app auth, OAuth provider, MCP resource server, enterprise SSO, and adapter authors.

Recommendation

If your team is building a TypeScript application and wants auth to live in code, Better Auth deserves evaluation now. The evidence supports that recommendation: MIT-licensed open source, 28,808 ToolVitals-tracked GitHub stars, a 98 ToolVitals score, a 100 shipping score, and recent releases focused on the hard parts of auth rather than surface polish.

Use the stable v1.6 line if you need production auth today and the current feature set covers you. Pay close attention to the v1.7 beta line if you are building OAuth provider functionality, protected resource modeling, MCP authorization, or advanced OIDC flows. That beta is where the strategic motion is.

Do not adopt it just because the hot score is high. Adopt it if the architecture matches your team: TypeScript, code-reviewed auth configuration, plugin-based extension, and a willingness to own auth behavior inside the app. If you need a hosted identity vendor with a mature dashboard, procurement support, and external operational ownership, ToolVitals cannot infer that Better Auth is already the safe choice.

The short version: Better Auth is one of the more serious open-source TypeScript auth projects to watch because its release stream is attacking the problems that make authentication hard in production. Evaluate it with the same seriousness. Auth is not a toy dependency, and this project is no longer acting like one.

Sources