Better Auth 1.7 升级时 OAuth Provider 客户端记录怎么从 oauthApplication 迁移到 oauthClient

Better Auth 1.7 升级时 OAuth Provider 客户端记录怎么从 oauthApplication 迁移到 oauthClient【免费下载链接】better-authThe most comprehensive authentication framework项目地址: https://gitcode.com/GitHub_Trending/be/better-auth把 Better Auth 从 1.6 升到 1.7 时OAuth Provider 的客户端存储从oauthApplication表变成oauthClient表同时会新增一组 token 表而旧版oauthAccessToken表名会和 1.7 的 token 表冲突。这篇文章只解决一件事客户端记录这一步数据迁移怎么做。它适用于三类 1.6 环境使用核心内oidcProvider插件、使用 MCP 插件或者已经在用better-auth/oauth-provider。为什么不能只靠升级命令1.7 升级指南的 schema 变更表中明确列出Provider client store 一项是「oauthApplicationbecomesoauthClient, plus new token tables」手动准备要求是move client data迁移客户端数据。指南同时警告升级命令npx auth upgrade只处理包更新数据库需要单独处理CLI 会添加表、列和索引但不会复制 OAuth 客户端记录也不会把oauthAccessToken.accessToken列改名为token必须在应用生成的 1.7 schema之前准备好 OAuth 客户端数据否则新 token 表建不出来或旧客户端直接丢失。所以这条迁移路径是先手动迁数据再应用 1.7 schema最后部署 1.7 包和配置。顺序不能反。迁移前的准备authCLI 要求 Node.js 22.12 或更新版本。用一条命令把better-auth和所有better-auth/*包一起升到 1.7保持 CLI 与库版本一致npx auth upgrade1.7 的oauthClient表结构可以在 OAuth Provider 插件文档 的 Schema 一节查到迁移时需要重点对齐的字段包括clientId唯一标识、clientSecret、redirectUrisstring[]必填、tokenEndpointAuthMethod支持none、client_secret_basic、client_secret_post、private_key_jwt、grantTypes支持authorization_code、client_credentials、refresh_token、responseTypes支持code、applicationType支持web、native、metadatajson。路径一1.6 核心内 oidcProvider 或 MCP 插件oauthApplication → oauthClient如果你用的是 1.6 的核心内oidcProvider插件或 MCP 插件按 1.7 升级指南 的 Migrate OAuth client records 一节对每一条oauthApplication记录执行复制或重新注册为oauthClient并完成以下数据转换字段映射把redirectUrls映射到redirectUris把metadata转换为 JSON为每个客户端设置 grant types 和 token-endpoint authentication method。过期旧 access token迁移客户端之后让旧的 access token 失效。处理旧 token 表在创建 1.7 的 token 表之前删除drop或重命名rename旧的oauthAccessToken表。文档特别指出 CLI 不会替你复制这些记录也不会把oauthAccessToken.accessToken列改名为token这一步必须手动完成。代码配置上1.7 移除了oidcProvider插件把来自better-auth/plugins的oidcProvider换成来自better-auth/oauth-provider的oauthProvider并把原配置迁移过去。如果 1.6 时运行的是 MCP 插件它随 1.7 移到独立的better-auth/mcp包文档要求把已注册的客户端走上面这条 OAuth client records 迁移OAuth 端点从/mcp/*迁到/oauth2/*发现机制discovery的客户端会自动找到新端点。另外两处与客户端记录直接相关的配置变更客户端配置和注册负载里裸 JWK 数组要换成 JWK Set 对象jwks: [key]改为jwks: { keys: [key] }。移除oauthProvider.silenceWarnings选项。路径二已在使用 better-auth/oauth-provider回填现有 oauthClient 行如果你 1.6 时已经用better-auth/oauth-provider客户端数据已经在oauthClient表里要做的不是换表而是按顺序回填新增三个可空列applicationType、clientDiscoveryId、clientCredentialsScopes。除非你有可信的 discovery 来源否则保持clientDiscoveryId为 null。把现有的web和native客户端类型映射到applicationTypeuser-agent-based客户端需要逐个单独审查。tokenEndpointAuthMethod只对公共客户端public client设为none其余方法一律视为 confidential。把clientCredentialsScopes设为空数组再给每个使用client_credentialsgrant 的客户端指派已批准的机器 scope同时从 provider 配置中移除clientCredentialGrantDefaultScopes。在添加复合唯一索引之前删除同一clientId和resourceId的重复oauthClientResource行。回填完成后删除已被移除的type和public列。两条路径的公共收尾JWK Set 格式调整jwks: [key]→jwks: { keys: [key] }和移除silenceWarnings选项同样适用。应用 1.7 schema 并部署客户端数据迁移完成后再动 schema使用内置 Kysely adapternpx auth migrate使用 Drizzle、Prisma 或自定义 schema 工作流先运行下面命令审查生成结果再用你自己的迁移工具应用npx auth generateschema 应用后把 1.7 包和配置变更一起部署。1.7 发布文章1.7 发布公告也强调了同样的顺序npx auth upgrade之后运行npx auth generate或npx auth migrate但不要认为生成的迁移就是完整升级——OAuth 客户端这类数据步骤必须人工完成。验证升级结果部署 1.7 后按升级指南的 Verify the upgrade 一节验证你的应用实际使用的路径作为身份提供方运行时走一遍 OAuth 授权authorization、刷新refresh、撤销revocation、discovery 和 protected-resource 检查运行了 MCP 的场景连接一个 MCP 客户端并完整走一次受保护请求。客户端能通过已迁移的oauthClient记录完成授权换 token、刷新 token 且 introspection 正常说明数据迁移成功。限制与注意事项顺序是唯一硬性约束数据迁移必须在应用 1.7 schema 之前完成CLI 不会复制客户端记录也不会把oauthAccessToken.accessToken列改名为token表名冲突只能手动 drop 或 rename 解决。1.7 移除了oidcProvider插件仍在使用它的代码必须在同一批变更里换成better-auth/oauth-provider否则部署后无法启动 OAuth 端点。本文只覆盖客户端记录迁移。1.7 的 account identityissuer列、SCIM 重新 provision、Device Authorization 唯一索引等其它手动步骤属于独立任务参见 1.7 升级指南 的对应章节按指南中的检查表判断你的项目是否适用。【免费下载链接】better-authThe most comprehensive authentication framework项目地址: https://gitcode.com/GitHub_Trending/be/better-auth创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考