GHSA-p2fr-6hmx-4528

### Am I affected? Users are affected if all of the following hold: - Their application depends on `@better-auth/oauth-provider` on any stable `1.6.x` release (the stable line is not patched) or on a pre-release before `1.7.0-beta.4`. - Their application either configures validAudiences` with more than one audience, or it issues JWT access tokens whose `aud`  (resource) claim is consumed by their resource servers. - Their resource servers make authorization decisions based on that `aud` or resource value. A deployment with a single `validAudiences` entry (or the default, their server's base URL) cannot mint a token for a different audience. The provider rejects any resource outside the allowlist. Such a deployment still does not bind the resource to the authorization grant, so the spec-compliance gap remains even where cross-audience escalation does not apply. Fix: 1. Upgrade to `@better-auth/[email protected]` (then `1.7.0`), then run the schema migration (`npx auth migrate`). This is a breaking change: a token or refresh request may only narrow the authorized `resource`, an uncovered resource returns `invalid_target`, and `customAccessTokenClaims` receives a `resources` array in place of `resource`. 2. The `1.6.x` stable line is not patched. If an application stays on it, developers should apply the workarounds below. ### Summary `@better-auth/oauth-provider` lets an OAuth client choose the access-token audience through the RFC 8707 `resource` parameter at the token endpoint. It does not bind that choice to the authorization grant. A client that completes a normal authorization flow can request a JWT access token whose audience targets a resource server the authorization never covered. The only constraint is that the resource appears in the server's `validAudiences` allowlist. The same gap applies to the refresh grant: a refresh token issued in a flow targeting one resource can be redeemed for an access token bound to a different allow-listed res