Threats affecting pkg:npm/@better-auth/oauth-provider

@better-auth/oauth-provider before 1.7.0-beta.4 fails to bind access-token audience to the authorization grant, allowing clients to request tokens for unrelated resources. Attackers can complete an OAuth flow and obtain access tokens whose audience targets resource servers the authorization never covered, bypassing intended authorization boundaries.

A race condition in @better-auth/oauth-provider versions >=1.6.0 and <1.6.11 allows concurrent redemption of the same OAuth authorization code. This occurs because the token endpoint uses a non-atomic find-then-delete operation to consume single-use authorization codes, enabling multiple token sets to be issued from one code. The issue also affects legacy plugins in better-auth versions >=1.4.8-beta.7 and <1.6.0. The vulnerability violates RFC 6749's single-use code requirement and can lead to multiple valid tokens from a single authorization code.

A vulnerability in @better-auth/oauth-provider versions >=1.6.0 and <1.6.11 allows concurrent refresh token redemption to fork the refresh token family. This occurs because the refresh token rotation process is not atomic, enabling two concurrent requests using the same refresh token to both succeed and mint new tokens. This breaks the intended single-use refresh token rotation and can allow indefinite access token renewal until expiration or revocation. The issue is fixed in version 1.6.11 by implementing an atomic compare-and-swap operation during token rotation and adding a unique constraint on refresh tokens.

The @better-auth/oauth-provider package versions in the stable 1.6.x line and pre-releases before 1.7.0-beta.4 allow OAuth clients to request access tokens for audiences (resources) that were not authorized during the initial authorization flow. This occurs because the provider does not bind the requested resource at the authorization endpoint to the token issuance, enabling clients to obtain tokens for any resource in the server's allowlist. The issue affects deployments that configure multiple valid audiences and rely on the audience claim for authorization decisions. The vulnerability is fixed in version 1.7.0-beta.4 and later, which enforce binding of resources to the authorization grant and restrict token issuance accordingly. Workarounds include limiting valid audiences to a single entry and configuring resource servers to reject tokens with unexpected audiences.