The `authorization_code` grant's verification step was a `findOne` + `deleteOne` pair, so two concurrent `POST /oauth2/token` requests sharing the same `code` both pass the find, both delete, and both mint independent access/refresh/id token sets: a CAS gap that lets an authorization code be redeemed twice. The legacy `oidc-provider` and `mcp` plugins in `better-auth` share the same primitive on their `authorization_code` paths and have the same gap.
All three call sites now use `internalAdapter.consumeVerificationValue` (the atomic primitive added in better-auth#9560 and renamed in better-auth#9568): the first concurrent caller receives the row and mints tokens, subsequent racers receive `null`. The consumed and expired paths return RFC 6749 §5.2 `invalid_grant` instead of the better-auth-internal `invalid_verification`, so spec-compliant clients can branch on the standard code. The redundant second `deleteVerificationByIdentifier` call after PKCE validation in the legacy paths is removed.
Closes GHSA-7w99-5wm4-3g79.
Co-authored-by: chdanielmueller <4051999+chdanielmueller@users.noreply.github.com>
The `authorization_code`-grant rotation in `createRefreshToken` and the explicit `revokeRefreshToken` path both updated the parent `oauthRefreshToken` row using an `id`-only predicate, so two concurrent rotations (or a rotation racing a revoke) both pass the `revoked` check and last-write-wins. Each surviving request mints a fresh refresh token, producing a forked family from one parent.
Both call sites now perform a compare-and-swap (`UPDATE ... WHERE id = ? AND revoked IS NULL`) and short-circuit with `invalid_grant` when the row was already consumed. The parent stays marked revoked, so any subsequent replay trips the existing family-invalidation guard in `handleRefreshTokenGrant`. The shared family-delete is centralized in `invalidateRefreshFamily`, which clears child access tokens before refresh rows to honor the schema's foreign-key direction; the `oauthRefreshToken.token` column also gains a `unique` constraint for parity with `oauthAccessToken.token`. Strict family invalidation on contested rotations (RFC 9700 §4.14) is tracked in a FIXME for a follow-up minor that opts into transactional rotation in the adapter contract.
Closes GHSA-392p-2q2v-4372.
Co-authored-by: chdanielmueller <4051999+chdanielmueller@users.noreply.github.com>
The init guard checked for `session` options broadly, which caused a
false error when users set any session config (e.g., `expiresIn`) without
secondaryStorage. Without secondaryStorage, sessions always persist to
the database, making the constraint irrelevant.
