Better Auth OAuth Provider 1.7 演进全解析：从 OAuth 2.1 安全默认值到 CIMD、DPoP 与资源模型

Better Auth OAuth Provider 1.7 演进全解析：从 OAuth 2.1 安全默认值到 CIMD、DPoP 与资源模型

【免费下载链接】better-authThe most comprehensive authentication framework项目地址: https://gitcode.com/GitHub_Trending/be/better-auth

@better-auth/oauth-provider是 Better Auth 生态中把任意应用变成 OAuth 2.0 / OIDC 授权服务器的核心插件，本文基于仓库内 packages/oauth-provider/CHANGELOG.md 的完整版本记录，系统梳理 1.7 系列引入的安全默认值、资源指示器模型、DPoP 发送者约束令牌、设备授权流程、Client ID Metadata Document（CIMD）支持与扩展机制，并配合 packages/oauth-provider/src 下的源码与测试给出可验证的实现细节。读完本文，你将掌握该插件 1.7 版的核心配置项、破坏性变更与数据库迁移步骤，能够安全地把自己的服务升级为一个符合 OAuth 2.1 / OpenID Connect 规范的授权服务器。

插件定位与版本脉络

@better-auth/oauth-provider是一个独立的 Better Auth 插件包，当前仓库版本为1.7.3（见 packages/oauth-provider/package.json）。它承担两类职责：

• 作为授权服务器（Authorization Server）：对外暴露/oauth2/authorize、/oauth2/token、/oauth2/introspect、/oauth2/revoke、/oauth2/register、/oauth2/userinfo、/oauth2/end-session等标准端点，并在/.well-known/oauth-authorization-server与/.well-known/openid-configuration发布发现文档。
• 作为基础设施底座：@better-auth/mcp插件即构建于其上（CHANGELOG 明确记载"MCP plugin moves out ofbetter-authinto its own package,@better-auth/mcp, built on@better-auth/oauth-provider"），因此 OAuth 端点的演进同时决定了 MCP 授权流的形态。

从 1.6 到 1.7，该插件的演进主线可以概括为四句话：向 OAuth 2.1 安全默认值靠拢、把受保护资源提升为一等公民、引入 CIMD 与 DPoP 两项新协议能力、以扩展机制承接未来 RFC。下面按主题逐层展开。

客户端模型与 OAuth 2.1 安全默认值

applicationType 取代 type / public 字段

1.7.0 起，OAuth 客户端开始存储applicationType，并在 OAuth 元数据中暴露为application_type。这一字段与tokenEndpointAuthMethod共同决定客户端的机密等级：

• tokenEndpointAuthMethod: "none"的客户端是公开客户端（public client）；
• 其余所有方法（client_secret_basic、client_secret_post、private_key_jwt）都视为机密客户端（confidential client）。

CHANGELOG 明确记载这是破坏性变更：旧有的type与public字段被移除，OAuthClient类型也不再带有 catch-all 字符串索引。如果要在 OAuth 线格式上携带自定义扩展字段，应当使用命名交叉类型显式建模，例如OAuthClient & YourExtensionMetadata。相关数据库字段定义可参见 packages/oauth-provider/src/schema.ts 中oauthClient模型（applicationType、tokenEndpointAuthMethod、clientCredentialsScopes等字段）。

默认值与重定向 URI 校验

• 动态注册、管理端注册与用户自管理注册中，省略application_type时默认补为web；而 Client ID Metadata Documents（CIMD）中省略该值时保持null。
• Web 客户端的重定向 URI 在非 loopback 主机上强制要求 HTTPS。
• Native 客户端接受三种形式：声明的 HTTPS URL、精确的 HTTP loopback 主机、以及反域名私有用途 scheme。其中私有用途 scheme 必须使用 RFC 8252 规定的单斜杠形式，例如com.example.app:/callback；HTTP loopback 主机只接受精确的localhost、127.0.0.1、[::1]，其他127.0.0.0/8地址与 localhost 子域一律拒绝。
• 重定向 URI 校验同时遵循 RFC 6749 §3.1.2，拒绝包含 fragment 片段的重定向 URI。校验实现位于 packages/oauth-provider/src/types/zod.ts 的SafeUrlSchema，其底层isSafeUrlScheme通过try/catch解析而非依赖URL.canParse，避免在不支持该 API 的运行时上静默失效（见 1.6.14 的修复记录）。
• 1.7.2 起，相对 callback 与 redirect URL 允许使用标准的 path、query、fragment 语法，但开放重定向保护依旧生效。

PKCE 与授权码流程

OAuth 2.1 默认要求 PKCE。1.7 系列在保持该默认的同时增加了一个可控开关：

• 新增配置项clientRegistrationRequirePKCE: false，允许服务器放行"通过动态注册创建的机密客户端在不带 PKCE 的情况下完成授权码流程"；
• 公开客户端与任何请求offline_access的授权请求仍然强制要求 PKCE，没有例外。

此外，redirect_uri在令牌端点采用条件校验（对齐 RFC 6749 §4.1.3）：只有授权请求携带了redirect_uri时才要求并匹配它；若授权码未绑定redirect_uri，则兑换时也无需提供。不匹配的redirect_uri现在返回invalid_grant而非invalid_request（RFC 6749 §5.2）。

受保护资源模型：RFC 8707 资源指示器

1.7 把"受保护资源"从配置数组升级为持久化的一等实体，这是理解新版授权语义的关键。

resources 取代 validAudiences

旧版通过服务器级validAudiences白名单校验资源，客户端可以在令牌请求中为任意白名单资源换取令牌。1.7.0 起：

• validAudiences被移除，资源标识符统一放入resources配置，或通过oauthResource管理 API 创建；
• 需要限制在特定资源内的客户端，通过oauthClientResource关联或动态注册中的resources字段绑定资源。

资源级令牌策略

每个资源可以独立定义令牌策略（对应 packages/oauth-provider/src/schema.ts 中oauthResource模型的字段）：

授权与令牌的绑定关系同样收紧：resource值在/authorize时被捕获并记录到授权 grant 上，令牌端点与刷新端点只能收窄、不能扩大授权覆盖的资源集合——请求授权未覆盖的资源返回invalid_target。刷新令牌保留原始 grant 的资源集合（RFC 8707 §2.2），/oauth2/introspect会报告令牌的aud。customAccessTokenClaims回调收到的参数也从单个resource字符串变为resources数组。

资源服务器侧

资源服务器应在其自身源上发布 RFC 9728 受保护资源元数据，插件提供createResourceServerChallenge（源码见 packages/oauth-provider/src/resource-challenge.ts）帮助把未认证/权限不足的请求转换为合规的 RFC 6750 challenge。@better-auth/mcp现在要求显式resource选项（例如resource: "https://api.example.com/mcp"），插件会把它存为 OAuth 资源、发布其保护资源元数据并把签发的访问令牌绑定到该资源。

DPoP 发送者约束令牌（RFC 9449）

1.7.0 引入 DPoP（Demonstrating Proof of Possession）绑定访问令牌，使令牌与客户端持有的密钥绑定，防窃取后异地重放。签发路径有三条：

1. 客户端注册时声明dpop_bound_access_tokens；
2. 授权请求携带dpop_jkt；
3. 请求的资源配置了dpopBoundAccessTokensRequired。

DPoP 令牌携带cnf.jkt确认声明、token_type返回"DPoP"（见 packages/oauth-provider/src/types/oauth.ts 中Confirmation与TokenType类型定义），并且绑定状态贯穿刷新令牌轮换、introspection 与 userinfo 全链路。

资源服务器使用verifyAccessTokenRequest校验Authorization: DPoP方案、proof、请求目标、访问令牌哈希与证明重放。反重放依赖数据库支撑的验证存储（createDpopReplayStore(internalAdapter)或自定义dpop.replayStore），跨实例生效；纯 secondary-storage 部署会直接拒绝 DPoP 请求而不是跳过反重放。破坏性变更方面，原verifyAccessToken更名为verifyBearerToken（better-auth/oauth2与oauthProviderResourceClient动作中同步改名），且该函数拒绝 DPoP 绑定令牌；输入类型AccessTokenRequestInput更名为ResourceRequestInput。

schema 迁移需要为访问令牌与刷新令牌表增加confirmation列，为客户端增加dpopBoundAccessTokens、为资源增加dpopBoundAccessTokensRequired。相关测试可参考 packages/oauth-provider/src/dpop.ts 与包内 DPoP 相关测试文件。

设备授权流程（RFC 8628）

1.7.0 起，已注册的 OAuth 客户端可以使用设备流程获取访问令牌。新版 API 是oauthDeviceAuthorization()，与oauthProvider()或mcp()组合使用（导出见 packages/oauth-provider/src/index.ts），取代了旧的独立deviceCodeGrant()插件与共享 grant 配置。

流程要点：

• 客户端在/device/code请求设备码，用户在/device页面确认后，客户端在/oauth2/token兑换令牌；
• OAuth 与 OpenID 发现文档都会广告device_authorization_endpoint；
• 设备授权请求可绑定 RFC 8707 资源指示器，令牌请求可以复用或收窄已批准的资源，但不能新增；
• 机密客户端用注册的认证方法访问/device/code，公开客户端只发送client_id；
• 未知的 OAuth 客户端 ID 只有在oauthDeviceAuthorization({ validateClient })接受时才进入独立设备流程；
• 独立设备授权不再接受或存储 RFC 8707 资源，onDeviceAuthRequest只接收clientId和scope。

启用该集成会为deviceCode增加可空的oauthClientId与resources字段，需要重新生成并应用 schema。相关实现与测试见 packages/oauth-provider/src/device-code.ts 与 packages/oauth-provider/src/device-code.test.ts。

动态注册与 Client ID Metadata Document（CIMD）

动态客户端注册（RFC 7591）

• 新增POST /oauth2/register的无会话注册路径：机器客户端可以在Authorization: Bearer头中携带 RFC 7591 initial access token，配合validateInitialAccessToken回调校验，直接创建公开或机密客户端，每个客户端可选携带所有者referenceId。
• 客户端创建端点对新建客户端返回201 Created（此前为200 OK）。
• 未认证的 DCR 请求中，若客户端声明client_secret_post/client_secret_basic或省略token_endpoint_auth_method（RFC 7591 默认client_secret_basic），服务器会静默改写为token_endpoint_auth_method: "none"（公开客户端），并在注册响应中把实际方法回传给客户端——这是与真实 MCP 客户端（如 Claude、Codex 等）互操作的关键修复。
• DCR 的 schema 接受skip_consent但动态注册时拒绝该值，防止权限提升。
• 可通过clientRegistrationRequirePKCE: false放宽 DCR 客户端的 PKCE 要求（仅限机密客户端，见上文）。

CIMD：以元数据文档 URL 作为 client_id

1.7.0 新增@better-auth/cimd包，实现 OAuth Client ID Metadata Document draft-02。其核心模型是：一个精确的 HTTPS 元数据文档 URL 就是 OAuth 的client_id，安装插件后 OAuth 发现文档会广告支持该能力；显式metadataProfile: "mcp-2026-07-28"模式则应用 MCP 2026-07-28 钉扎的 draft-00 元数据要求。

安全边界非常严格（CHANGELOG 逐条列出）：

• 拒绝客户端密钥、私有 JWK 材料、back-channel logout 元数据、服务器自有字段、不安全的元数据 URL、非 JSON 响应、超大文档、重定向，以及私有/保留网络目标；loopback Client Identifier URL 不再支持。
• 客户端 JWKS 统一通过单一"公钥非对称"边界校验：必须是 RFC 7517 JWK Set 形式{ "keys": [...] }（裸数组形式jwks: [key]已移除）；EC 密钥仅限 P-256 / P-384 / P-521，OKP 密钥仅限 Ed25519；声明alg时必须与密钥类型和曲线匹配。
• 元数据获取遵循 HTTP 共享缓存新鲜度规则并"失败即关闭"：优先s-maxage而非max-age/Expires，支持 ETag / Last-Modified 条件再验证，Cache-Control: private与Vary: *不可缓存，无条件304被拒绝，无效或重复的新鲜度指令视为立即过期。
• metadataFetchPolicy限制元数据请求放大：同客户端请求合并、按客户端节流、全局/按源并发立即拒绝、滚动 60 秒预算封顶唯一客户端喷发。
• Node.js 部署可从@better-auth/cimd/node导入fetchClientMetadataResource：只解析一次、拒绝任何非公网 DNS 答案、钉扎已批准连接（不进入全局 HTTPS 连接池）、保留 Host 与 TLS 证书身份、不缓冲地返回重定向与响应体。
• 客户端行新增可空clientDiscoveryId作为发现来源凭据：发现 ID 全局唯一，被管理的客户端在其匹配发现不可用时"失败即关闭"，只有该发现能刷新客户端或为其元数据所属资源提供传输，从而防止托管/DCR HTTPS 客户端 ID 被接管。

extendOAuthProvider扩展面同时暴露clientDiscovery，供自定义已验证客户端解析插件使用（见 packages/oauth-provider/src/extensions.ts）。

令牌端点硬化与 RFC 合规错误语义

1.7 系列对令牌端点的 RFC 合规性做了系统性加固，主要分三层：

标准错误信封

所有 OAuth 端点（/oauth2/token、/oauth2/authorize、/oauth2/revoke、/oauth2/introspect、/oauth2/register、/oauth2/end-session）对畸形请求返回标准{ error, error_description }信封：

• 缺失必需字段 →invalid_request；
• 客户端认证失败 →invalid_client；
• 无效或不匹配的 grant →invalid_grant；
• HTTP Basic 认证失败返回401并带WWW-Authenticatechallenge。

/oauth2/authorize的校验失败在能解析到受信任重定向 URI 时重定向回客户端（携带error、error_description、回显state与iss），并根据响应类型选择传输方式：implicittoken/id_token响应走 URL fragment，除非客户端显式请求 query 模式；无法解析受信任 URI 时回落到服务器错误页。

敏感响应禁止缓存

携带凭据的响应统一发送Cache-Control: no-store与Pragma: no-cache，覆盖令牌、introspection、userinfo、动态/管理端注册、客户端密钥轮换以及设备码/设备令牌端点（含错误响应）。端点通过metadata: { noStore: true }声明，@better-auth/core导出NO_STORE_HEADERS供手写响应复用（对应测试见 packages/oauth-provider/src/no-store.test.ts）。

重放与凭据语义收紧

• 授权码重放：返回invalid_grant+400，并吊销该授权码此前签发的所有不透明令牌。
• 刷新令牌重放：默认严格处理；可选refreshTokenReuseInterval开启重叠窗口，让重复刷新请求取回轮换前的同一响应（@better-auth/mcp默认 30 秒，设refreshTokenReuseInterval: 0可关闭）。
• 凭据解析：空凭据视为省略；重复的非空客户端凭据被拒绝；机密客户端必须使用注册的token_endpoint_auth_method；introspection / revocation 忽略无法识别的token_type_hint。
• 跨客户端刷新令牌：使用其他客户端签发的刷新令牌返回invalid_grant+invalid refresh token。
• 按客户端 grant 类型强制：client_credentials与authorization_code只在客户端声明时才允许，否则返回unauthorized_client；无记录的客户端回落到["authorization_code"]注册默认值。
• JWT 撤销语义：对仍可验证的 JWT 访问令牌调用/oauth2/revoke返回400 unsupported_token_type（JWT 自包含、未存储、无法真正撤销）；已过期或受众不匹配的 JWT 仍返回成功的200no-op。要切断 JWT 访问，应结束会话（登出、管理端吊销或回通道登出）。

OIDC 细节：at_hash、claims、max_age、acr 与注销

ID 令牌完整性

• ID 令牌现在按 OIDC Core §3.1.3.6 计算at_hash，把 ID 令牌与访问令牌密码学绑定，防止令牌替换攻击。哈希算法按实际签名密钥算法选择：EdDSA/Ed25519 用 SHA-512，RS/ES/PS384 用 SHA-384，RS/ES/PS512 用 SHA-512，其余用 SHA-256。better-auth/plugins新增resolveSigningKey()导出用于解析当前 JWKS 签名密钥（含算法）。
• customIdTokenClaims、扩展 ID-token claims 与每次签发的idTokenClaims都不能再设置协议级声明（issuer、subject、audience、令牌生命周期、nonce、会话/哈希绑定、auth_time、acr、amr、azp）；带命名空间的用户自定义 claims 仍会出现在 ID 令牌中。
• ID 令牌默认携带acr: "0"（表示认证未达到 ISO/IEC 29115 level 1），发现文档只广告"0"；acr_values为自愿参数，请求其他类别时流程继续而不是失败，但 OIDC 流程中 essential 的claims.id_token.acr请求在无法满足 requiredvalue/values时仍会失败。

claims 参数与 max_age

• 授权端点现在支持claims.userinfo参数：客户端可请求单个标准声明，UserInfo 端点返回 scope 覆盖之外的可用声明；被请求声明纳入用户 consent，发现文档广告claims_parameter_supported。未请求openidscope 就使用claims参数的请求被拒绝。注意：带 JWT 访问令牌时 UserInfo 只返回已授权 scope 覆盖的声明，因此需要特定声明时必须请求对应 scope。这需要为访问令牌、刷新令牌与 consent 表增加requestedUserInfoClaims列。
• max_age从"接受但忽略"变为强制执行：若用户认证时间早于请求窗口，授权服务器把用户送回登录，新 ID 令牌的auth_time反映新鲜登录。相关逻辑可见 packages/oauth-provider/src/authorize.ts 中的isWithinMaxAge纯函数。
• 授权端点新增 form-encoded POST 支持，并对不支持的 OpenID Connect request object 显式返回request_not_supported/request_uri_not_supported。

登出与 Back-Channel Logout 1.0

当用户的会话在 OP 侧结束时（登出、/oauth2/end-session、管理端吊销、封禁），插件会通知所有持有该会话令牌的 Relying Party，并立即切断 API 访问，而不是等访问令牌自然过期：

• 每个客户端通过 DCR 或管理端创建接口注册backchannel_logout_uri（可选backchannel_logout_session_required）；
• 服务器为每个客户端签名logout+jwtLogout Token 并并行 POST，带短超时；
• 会话结束后，introspection 返回{ active: false }，/oauth2/userinfo以invalid_token拒绝（这是破坏性变更：访问令牌不再活过会话生命周期）；无offline_access的刷新令牌在会话结束时被吊销，带offline_access的刷新令牌保留（OIDC Back-Channel Logout 1.0 §2.7）；
• 交付走宿主后台任务处理器（VercelwaitUntil、Cloudflarectx.waitUntil），未配置时内联完成以免通知在请求拆解时丢失；serverless 环境可配置advanced.backgroundTasks.handler；
• backchannel_logout_uri必须是免凭据的公网 HTTPS URL 且无 fragment，loopback HTTP 对公开与机密客户端均拒绝，CIMD 文档不能注册 back-channel logout 元数据；SSRF 主机防护同时覆盖private_key_jwt客户端的jwks_uri；
• RP-Initiated Logout 端点继续接受GET，新增 form-encodedPOST与 Better Auth 生成客户端的 JSON 请求体；浏览器用户可在显式确认后无id_token_hint登出；登出重定向要求精确匹配已注册的post_logout_redirect_uri。

Schema 变更：oauthClient.backchannelLogoutUri、oauthClient.backchannelLogoutSessionRequired、oauthAccessToken.revoked。

private_key_jwt 客户端认证（RFC 7523）

令牌端点客户端认证支持private_key_jwt：服务器验证非对称密钥签名的 JWT 客户端断言，客户端在授权码、刷新与客户端凭据三类令牌请求中复用同一契约。

• @better-auth/core/oauth2导出signPrivateKeyJwtClientAssertion、createPrivateKeyJwtClientAssertionGetter、PrivateKeyJwtSigningAlgorithm、PRIVATE_KEY_JWT_SIGNING_ALGORITHMS；断言 getter 接收{ clientId, tokenEndpoint, grantType }。
• createPrivateKeyJwtClientAssertionGetter在构造时即做急切校验：不支持的算法（HS256、none）、无密钥材料的 JWK、显式algorithm与 JWK 内嵌alg冲突都会在构造时抛错。
• 客户端断言aud可以是接收端点 URL 或 OIDC issuer（字符串或包含至少一个可接受值的数组），适用于 token、introspection 与 revocation。
• 服务端jwks元数据只接受含非空keys数组的 RFC 7517 JWK Set 对象；consumeClientAssertion辅助函数（packages/oauth-provider/src/utils/client-assertion.ts）负责 RFC 7523 的 audience、生命周期与jti重放检查。
• encodeBasicCredentials/decodeBasicCredentials遵循 RFC 6749 §2.3.1（逐值 form-urlencoded、仅按第一个冒号分割），解码端大小写不敏感并容忍凭据前一个或多个空格，使含保留字符的密钥跨栈往返无损。

扩展机制：extendOAuthProvider

为了"为每个 OAuth RFC 改 provider 核心"不再成为常态，1.7.0 新增扩展面，让伴生插件可以注册：

• 令牌 grant 类型；
• 基于断言的客户端认证方法；
• 附加的发现元数据；
• 访问令牌 / ID 令牌 / UserInfo 声明贡献者；
• 客户端 ID 发现来源。

在插件init()钩子中调用extendOAuthProvider(ctx, extension)注册即可。边界约束明确：grant 类型、认证方法与断言类型跨扩展必须互不相交；元数据与声明是附加性的，绝不能覆盖授权服务器核心；断言的客户端认证策略只证明调用方掌控哪个 client id，授权服务器自行解析并授权客户端记录——策略无法影响客户端的 grant、scope 或启用状态，handler 也无法在签发一个 grant 的同时授权另一个。

grant handler 收到provider对象（解析客户端、签发令牌、哈希/查找令牌、验证令牌），插件自己的端点通过getOAuthProviderApi(ctx, opts, grantType?)获取同一对象；通过向issueTokens传confirmation（RFC 7800cnf）或从客户端认证策略返回它，可以让签发的令牌被发送者约束，但cnf由授权服务器独占，声明贡献者无法设置。相关测试见 packages/oauth-provider/src/extensions.test.ts。

升级与迁移清单

综合 1.7 全系列的破坏性变更，从 1.6 或 1.7 prerelease 升级时需要按顺序处理：

1. 数据库迁移：执行npx auth migrate（或自行管理 schema 时npx auth generate）。涉及的表与列包括：
   • oauthClient：新增applicationType、可空clientDiscoveryId、clientCredentialsScopes（默认[]）、backchannelLogoutUri、backchannelLogoutSessionRequired、dpopBoundAccessTokens；移除type/public遗留列。
   • oauthAccessToken/oauthRefreshToken/oauthConsent：新增confirmation、requestedUserInfoClaims、revoked等列。
   • 新增oauthResource、oauthClientResource、oauthClientAssertion、oauthRefreshToken表；jwks表新增可空alg、crv列。
   • deviceCode：新增可空oauthClientId与resources（使用oauthDeviceAuthorization()时）。
   • 迁移映射规则：web/native直接映射；user-agent-based映射为NULL待人工重分类；绝不从public推导；clientDiscoveryId只能来自已知发现来源，绝不能通过检查 HTTPS 客户端 ID 推断；在加(clientId, resourceId)复合唯一索引前先对既有链接去重。
2. 配置清理：删除validAudiences（迁入resources）；删除silenceWarnings选项；为@better-auth/mcp补resource选项；删除clientCredentialGrantDefaultScopes（改为逐客户端审计后显式指派client_credentials_scopes，该字段只有管理端 create/update 端点可设置且需要configure-client-credentials-scopes特权动作）。
3. 客户端侧 API 适配：signIn.oauth2({ providerId })→signIn.social({ provider })；oauth2.link()→linkSocial()；callback URL 从/api/auth/oauth2/callback/:id变为/api/auth/callback/:id；genericOAuthClient()移除；jwks: [key]全部改为{ keys: [key] }。
4. MCP 组合：MCP 客户端需要 scope 墙提示时配置requiredScopes/isScopeSatisfied；mcp()不再隐式开启未认证 DCR，需要 CIMD 时与cimd()组合或显式开启 DCR 标志。

测试与验证

该包的测试覆盖非常完整，是理解各主题行为的最佳佐证，包括但不限于：

• packages/oauth-provider/src/authorize.test.ts、packages/oauth-provider/src/authorize-loopback.test.ts：授权端点与 loopback 重定向匹配；
• packages/oauth-provider/src/token.test.ts、packages/oauth-provider/src/private-key-jwt.test.ts、packages/oauth-provider/src/private-key-jwt-e2e.test.ts：令牌端点与 RFC 7523 断言认证；
• packages/oauth-provider/src/backchannel-logout.test.ts、packages/oauth-provider/src/logout.test.ts：登出链路；
• packages/oauth-provider/src/resources.test.ts、packages/oauth-provider/src/resource-binding.test.ts、packages/oauth-provider/src/resources-e2e.test.ts：资源模型与授权绑定；
• packages/oauth-provider/src/device-code.test.ts：设备流程；
• packages/oauth-provider/src/claims.test.ts、packages/oauth-provider/src/pkce-optional.test.ts、packages/oauth-provider/src/introspect.test.ts、packages/oauth-provider/src/revoke.test.ts、packages/oauth-provider/src/client-jwks.test.ts、packages/oauth-provider/src/signed-query.test.ts。

小结

从 1.6 到 1.7，@better-auth/oauth-provider完成了一次从"可用"到"严格合规"的蜕变：OAuth 2.1 安全默认值（PKCE、loopback 校验、应用类型建模）、RFC 8707 资源模型、RFC 9449 DPoP、RFC 8628 设备流程、CIMD、RFC 7591 动态注册与 Back-Channel Logout 共同构成了一张完整的现代授权服务器能力图；extendOAuthProvider扩展面则让后续 RFC 的接入不必再改动核心。升级时务必按上文清单先完成数据库迁移与配置清理，再逐步验证授权、令牌、introspection 与登出各端点行为，确保从旧语义平滑过渡到新的安全模型。

【免费下载链接】better-authThe most comprehensive authentication framework项目地址: https://gitcode.com/GitHub_Trending/be/better-auth