docs/content/blogs/1-7.mdx
We're excited to announce Better Auth 1.7 🎉
Better Auth 1.7 is one of our largest releases. It brings major improvements across OAuth and OpenID Connect, enterprise identity, MCP authorization, and device access.
If other applications sign in through your app, the OAuth provider now supports stronger tokens, explicit rules for protected APIs, more client authentication methods, and broader OpenID conformance. If your customers provision employees through SCIM, 1.7 adds Groups, role projections, richer employee profiles, and an optional bridge to SSO. MCP clients and limited-input devices can also request standards-based OAuth access.
We introduced the first part of this work in the 1.7 release candidate. Some improvements require migration work, especially for OAuth Provider, MCP, SSO, SAML, SCIM, account identities, and custom storage. The highlights below explain what each area gains. Follow the 1.7 upgrade guide for the migration steps.
<HeaderLabel variant="info">Expanded</HeaderLabel>
The OAuth provider is the center of Better Auth 1.7. It already let other apps sign users in and request access. This release adds stronger client authentication, explicit rules for each protected API, DPoP, sign-out across connected apps, and broader OpenID conformance.
We also tested 1.7 with the official OpenID Conformance Suite. It now handles more of the tested rules for login, token refresh, client registration, key rotation, and logout. These results are not a certification claim, and some optional OpenID features remain unsupported.
The main additions are:
max_age now works as intended, so an app can require a recent login before a sensitive action.The provider can also be extended without changing its core. That is how the new MCP, Client ID Metadata Documents (CIMD), and device authorization features plug into the same OAuth system.
If you still use the deprecated oidcProvider plugin, migrate to @better-auth/oauth-provider. The replacement provider existed before 1.7, and 1.7 removes the old plugin.
<HeaderLabel variant="info">New</HeaderLabel>
MCP authentication now lives in its own package, @better-auth/mcp. It uses the OAuth provider from this release, supports the MCP 2026-07-28 authorization profile, and works with version 2 of the official MCP TypeScript SDK.
The responsibilities are clear: Better Auth handles login, consent, and access tokens. The official MCP SDK handles the messages sent between an MCP client and server.
The new package keeps the existing stateless bearer-token model and makes it safer to run across several server instances. Better Auth still stores normal login records, such as clients, consent, and refresh tokens.
The package expands MCP authorization with:
@better-auth/cimd lets an MCP client identify itself with a document on its own website. Older clients can still use Dynamic Client Registration when you enable it.Separate MCP services are now easier to configure because they can check tokens made explicitly for that service. Existing MCP setups need a migration because the package, setup, and OAuth paths have changed.
<HeaderLabel variant="info">New</HeaderLabel>
Better Auth already supported signing into the same application from a device with limited input. A new RFC 8628 grant expands that flow to registered OAuth clients. A CLI, smart TV, game console, or IoT device shows a code, and the user approves API access in a browser.
The approval page shows which app is asking and what it wants to access. After approval, the device receives a normal OAuth token for that API. It cannot ask for extra access after the user has approved the request.
This is separate from Better Auth's existing device sign-in flow, so both can run in the same application. It also works with products that ship their own MCP command-line tool. See the device authorization documentation for both options.
<HeaderLabel variant="info">Rebuilt</HeaderLabel>
Better Auth 1.6 already let enterprise directories create, update, deactivate, reactivate, and remove Users. Better Auth 1.7 rebuilds that service around isolated connections and adds first-class Groups, direct memberships, role projections, and richer employee profiles.
Connections now own their Users, Groups, memberships, and credentials. A separate provisioning domain defines where those changes apply in your product, such as a workspace, tenant, project, or organization.
The rebuilt service includes:
admin or billing.Better Auth 1.7 replaces the legacy runtime management endpoints with 2 application-controlled options: resolve connections from your own catalog, or use the managed catalog built into the SCIM plugin.
The managed catalog supports several credentials per connection, with their own permissions and expiry dates. It can rotate and revoke credentials, record who made each change, and retire a connection safely. New secrets are returned only when they are created or rotated, while Better Auth stores protected digests instead of plaintext values.
If your application already manages customer connections, it can verify a credential and return the matching connection in one safe operation instead of adopting the managed catalog.
SCIM creates and manages employee records, but it does not sign employees in. Better Auth 1.7 adds an explicit, transaction-safe bridge from a SCIM identity to a verified SSO identity.
Applications can configure this bridge so OpenID or SAML signs in the exact User created or linked by SCIM. The match uses the stable identity confirmed by both systems, not an email or username. When this integration is configured, an inactive, deleted, or decommissioned directory identity is rejected on its next SSO attempt.
The Next.js demo shows the configured integration. An administrator creates a connection, adds Users and Groups, changes access, disables employees, and later restores them. A separate employee view shows session revocation, rejected sign-ins, reactivation, and reprovisioning.
SCIM 1.7 replaces the previous setup and database model. Existing installations need a planned cutover and must ask their directory to send all users and groups again. Cloudflare D1 is not supported because it cannot provide the database transactions this flow needs. Follow the SCIM migration steps before turning provisioning back on.
<HeaderLabel variant="warning">Breaking</HeaderLabel>
External accounts now use a trusted provider identity plus the stable subject confirmed by that provider. OpenID uses sub, SAML uses the signed NameID, and plain OAuth providers use their declared account ID.
Configurations that return the same trusted provider and subject now share one identity. Equal subject values from different providers remain separate. Existing applications need to review and migrate their saved account identities.
The SSO plugin builds on that model:
With an exact mapping configured, SCIM and the paired login provider can point to the same Better Auth User. See the SSO documentation for the final setup.
<HeaderLabel variant="info">Expanded</HeaderLabel>
Better Auth as an OAuth client also received a large update. Generic OAuth providers now use the common social sign-in client path instead of a separate client plugin. PKCE is on by default, and providers configured through discovery get stronger identity-token and nonce checks.
You can also change provider options for one sign-in. This supports choosing an Amazon Cognito provider, giving Microsoft Entra ID a domain hint, or asking Google for offline access. Entra ID and custom providers can use signed keys instead of shared secrets. Providers such as Auth0 and Zitadel can receive the extra information they need when a token refreshes, without sending the user through login again.
Scopes already granted to an account now survive later sign-ins and token refreshes.
Provider-started OpenID login can restart through a fresh protected login flow when enabled. Anonymous account linking also works in Expo and other in-app browsers.
<HeaderLabel variant="info">Also included</HeaderLabel>
@better-auth/i18n expands its catalog to 22 languages.hydrateSession gives the browser the session that the server already loaded, avoiding another request.npx auth create-admin creates an administrator from the command line.fetch-compatible handler is expected.user.validateUserInfo can reject a user before creation or account linking across OAuth, SSO, credentials, passwordless methods, and SCIM.The table below shows where to start. The 1.7 upgrade guide contains the exact schema, data, configuration, and API changes.
| If you use | Start here |
|---|---|
| Basic Better Auth setup | Upgrade all Better Auth packages together, then generate and review schema changes |
| Social login, custom OAuth, One Tap, or SSO | Review how existing accounts map to identities confirmed by each provider |
@better-auth/oauth-provider | Review saved clients and apply the database changes for protected APIs, stronger tokens, and logout |
| MCP | Install @better-auth/mcp, update the integration, and apply the OAuth client database changes |
| Device authorization | Apply the device-code database changes and choose between app sign-in and OAuth access |
| SAML or SSO | Review saved account identities, provider settings, certificates, and callback URLs |
| SCIM | Stop provisioning, replace the old setup, create new credentials, then send all Users and Groups again |
| Expo or React Native | Await cookie reads and update custom secure-storage implementations |
| Two-factor authentication | Review OTP and TOTP enrollment and handle the new enableTwoFactor response shape |
| Magic links or email OTP | Review the new cleanup behavior for accounts whose mailbox was not confirmed |
| Custom adapters, storage, or rate-limit stores | Add the new methods for safe one-time actions and counters before deploying |
| Custom proxy or TLS termination | Confirm that Better Auth knows the public URL of your application |
Upgrade better-auth and every @better-auth/* package together:
npx auth upgrade
Then run npx auth generate or npx auth migrate for schema changes. Do not treat the generated migration as the full upgrade: account identity, OAuth clients, MCP, and SCIM need reviewed manual data steps. The upgrade guide walks through each one.
Thanks to all the contributors for making this release possible!
export const releaseContributorUsernames = [ // cspell:disable "0-Sandy", "0xHouss", "9hsein5", "aarmful", "adityachaudhary99", "adrianmxb", "ahmedivy", "allandelmare", "Andrew1326", "arnnvv", "baptisteArno", "Bekacru", "Bekione", "bennettdams", "benpsnyder", "birkskyum", "bjorntechTobbe", "brentmitchell25", "brone1323", "bytaesu", "Byte-Biscuit", "CatLover01", "cb-alish", "chdanielmueller", "ChrisMGeo", "Craga89", "cyphercodes", "demhadais", "dipan-ck", "DougInAMug", "dvanmali", "ejirocodes", "ElGauchooooo", "elliotBraem", "eluce2", "Emmaccen", "erquhart", "fabian-hiller", "FaryalRizwaan", "florianamette", "formatlos", "frankeld", "GautamBytes", "GoPro16", "gustavovalverde", "himself65", "IcanDivideBy0", "IdrisGit", "ItalyPaleAle", "Jadenstanton", "jashkarangiya", "jaydeep-pipaliya", "jeroenvandermerwe", "jjluzgin", "jlucaso1", "jonathansamines", "jsj", "kgarg2468", "KingIronMan2011", "Kinfe123", "krish-vachhani", "Ktryberceo", "Kvizas", "lubiah", "mausic", "momomuchu", "moonevm", "mrosberghaus", "MuzzaiyyanHussain", "nphlp", "Oluwatobi-Mustapha", "OliverCordingl1", "onmax", "OscarCornish", "ouwargui", "Paola3stefania", "pbacza", "peyremorgan", "pi0", "ping-maxwell", "programming-with-ia", "rachit367", "ramonclaudio", "reslear", "ruban-s", "Saiyaswanthpasupuleti", "seanfilimon", "seebykilian", "SferaDev", "skalkii", "sleepe229", "sovetski", "stewartjarod", "TanishValesha", "terijaki", "tonytkachenko", "tsokolovs", "tsushanth", "Tushar-Khandelwal-2004", "Vishesh-Verma-07", "WilsonnnTan", "wobedi", "XXMOHAMED012", "yordis", "zeroknowledge0x", "zllovesuki", // cspell:enable ];
<Contributors usernames={releaseContributorUsernames} />