`resource` parameter not included in token request per RFC 8707

[DibyodyutiMondal]

Description

When the resource parameter is configured in UserManagerSettings, it is only sent in the authorization request but not in the token exchange request. This violates RFC 8707 (Resource Indicators for OAuth 2.0), which requires the resource parameter to be included in both requests.

RFC 8707 Requirement

From Section 2 of RFC 8707:

When the resource parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) where the client intends to use the requested access token.

When the resource parameter is used in an access token request to the token endpoint, it indicates the identity of the protected resource(s) for which the access token is being requested.

The spec makes it clear that the resource parameter should be sent in both the authorization request and the token request.

Current Behavior

const manager = new UserManager({
  authority: 'https://auth.example.com',
  client_id: 'my-client',
  redirect_uri: 'https://app.example.com/callback',
  scope: 'openid profile email',
  resource: 'https://api.example.com',  // Only sent to /authorize, not /token
});

• Authorization request to /authorize: includes resource=https://api.example.com ✓
• Token request to /token: missing resource parameter ✗

Expected Behavior

The resource parameter should be automatically included in the token request when configured in settings, matching the behavior of the authorization request.

Workaround

Currently, users must manually duplicate the resource in extraTokenParams:

const manager = new UserManager({
  // ...
  resource: 'https://api.example.com',
  extraTokenParams: {
    resource: 'https://api.example.com'  // Manual workaround
  },
});

Impact

This affects OAuth providers that implement RFC 8707 and use the resource parameter to determine token format (e.g., JWT vs opaque tokens). Without the resource in the token request, the authorization server may:

• Issue opaque tokens instead of JWT tokens
• Fail to set the correct aud claim
• Reject the token request entirely

(specifically, I'm using better-auth for my OIDC server)

Related Issues

• VS Code OAuth2 Flow Violates RFC 8707: Missing Resource Parameter in Token Exchange Request microsoft/vscode#261364 - Same issue in VS Code's OAuth implementation
• Fix OAuth2 resource parameter compliance with RFC 8707 microsoft/vscode#261815 - PR fixing this in VS Code

Suggested Fix

In the token request logic, include the resource from settings alongside other parameters, similar to how it's handled in the authorization request.

[pamapa]

Thanks for the very good detailed text of analysis.

Suggested Fix
In the token request logic, include the resource from settings alongside other parameters, similar to how it's handled in the >authorization request.

Makes sense

[DibyodyutiMondal]

Following up — the same bug exists on the refresh-token grant, and there the extraTokenParams workaround doesn't help either.

The Problem

TokenClient.exchangeRefreshToken builds its request purely from the passed-in args; it never merges settings.resource or settings.extraTokenParams:

async exchangeRefreshToken({ grant_type = "refresh_token", ..., ...args }) {
  const params = new URLSearchParams({ grant_type });
  for (const [key, value] of Object.entries(args)) { /* only `args` */ }
}

exchangeCode, by contrast, spreads ...state.extraTokenParams (seeded from settings). So on refresh, nothing from settings reaches the token endpoint — not resource, not extraTokenParams.

Real-World Impact

Against an AS that gates access-token format on the resource/audience (e.g. @better-auth/oauth-provider, which only signs a JWT when a valid resource is present), the same client config yields a JWT on initial sign-in (authorization_code) but an opaque token on silent renew (refresh_token) — so JWT validation on the resource server breaks after the first rotation.

Workaround

Pass the values as call args to signinSilent (these do flow through to exchangeRefreshToken). To also cover automaticSilentRenew (which calls signinSilent() with no args), extend UserManager and inject them from settings:

class CustomUserManager extends UserManager {
  override signinSilent(args: SigninSilentArgs = {}) {
    return super.signinSilent({
      resource: this.settings.resource,
      extraTokenParams: this.settings.extraTokenParams,
      ...args,
    });
  }
}

A proper fix would merge settings.resource / settings.extraTokenParams into exchangeRefreshToken, mirroring exchangeCode.