feat(auth): support RFC 8707 resource indicators on the PKCE provider

[scottlovegrove]

createPkceProvider had no way to request an audience-targeted token. Only createDcrProvider accepted a resource, so a public client whose authorization server and API are different origins had to either fake a registration flow it doesn't need or reimplement AuthProvider outright.

This adds resource to PkceProviderOptions, taking the same literal-or-resolver form as authorizeUrl / tokenUrl / clientId. It is applied to the authorize URL and to both the authorization_code and refresh_token token requests.

The refresh leg is the part with no workaround today. tokenRequestParams could already inject a resource into the code exchange, but nothing could reach the refresh grant — refreshToken built its TokenEndpointRequestOptions with only signal and customFetch — so a rotated token came back with the wrong audience and the CLI would start failing some hours after a successful login.

Two smaller things fall out of it:

• resolveResource moves from dcr.ts into the shared oauth.ts helpers, now that both providers use it. No behaviour change on the DCR side.
• On the token request the resource is set before the caller's tokenRequestParams extras, so a consumer already injecting one by hand keeps winning. That preserves the precedence that held before resource became a first-class option.

Why now

The Automations CLI needs a client ID metadata document client against Todoist's authorisation server: the document's https URL is the client_id, there is no registration step, the client is public with mandatory PKCE, and the token has to carry resource=https://automations.todoist.com so it is minted for the Automations API rather than the Todoist one.

Everything there except the resource indicator already worked — nothing in cli-core cares what shape a client_id is, so the document URL passes straight through. The alternative was createDcrProvider with a stub loadClient that short-circuits registration and returns a hardcoded client, which works but reads as a lie and drags in the oauth4webapi peer dep for login. With this change it is plain createPkceProvider, and the README documents that combination as its own quick-start section.

Tests

Five new cases on createPkceProvider: resource on the authorize URL and the code exchange (using a metadata-document client_id), lazy resolution from handshake/flags, resource on the refresh grant, tokenRequestParams overriding it, and no stray resource parameter anywhere when the option is unset. Full suite green: 540 passing.

[doistbot]

This PR threads RFC 8707 resource indicators through createPkceProvider — applied to the authorize URL and both token grants — mirroring the existing DCR handling and moving resolveResource into the shared oauth.ts helpers.

Few things worth tightening:

• The tokenRequestParams.resource override can break RFC 8707 compliance on the code exchange: if the configured resource is A but the override returns B, the authorization request carries A while the token request carries B, which a compliant server must reject. Consider making the configured resource win, or deriving one effective resource for both requests.
• tokenRequestParams is built after resource resolution finishes, but its inputs (handshake, flags) are already available — starting it in parallel would make exchange latency max(tokenUrl, resource, extras) instead of max(tokenUrl, resource) + extras, while keeping the existing spread order for override precedence.

I also left one optional follow-up note in the details below.

Optional follow-up note (1)

• src/auth/providers/pkce.ts:226: The inline additionalParameters: { resource } + [oauth.customFetch] construction here duplicates exactly what dcr.ts's tokenRequestOptions(oauth, fetchImpl, resource, signal) helper already does. Both factories now build the same RFC 8707 / custom-fetch / abort-signal token-request options, and this PR already moved resolveResource into oauth.ts for the same sharing reason. Consider extracting tokenRequestOptions (or an equivalent refreshTokenRequestOptions) into oauth.ts and reusing it from both providers instead of re-rolling it inline in refreshToken.

_{Share Feedback • Review Logs}

[doist-release-bot]

🎉 This PR is included in version 1.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[craigcarlyle]

✅