Skip to content

feat(oauth): accept extra token request parameters on a registered OAuth client - #2398

Open
Adityakk9031 wants to merge 6 commits into
UsefulSoftwareCo:mainfrom
Adityakk9031:feat/oauth-client-token-params
Open

Adityakk9031 wants to merge 6 commits into
UsefulSoftwareCo:mainfrom
Adityakk9031:feat/oauth-client-token-params

Conversation

@Adityakk9031

Copy link
Copy Markdown
Contributor

Summary

Fixes #2265.

Some providers need provider-shaped, NON-secret parameters on every token request that no OAuth grant field carries. Auth0 is the motivating case: its Management API only issues a client_credentials token when the request names the API in audience, and resource is ignored on that grant. A registered (BYO) OAuth app can now carry a tokenParams map (e.g. {"audience": "https://…/api/v2/"}), which executor sends on the client-credentials exchange, the authorization-code exchange, and every refresh (form and JSON transports alike), including the proactive re-mint at refresh time. Existing clients without the map are unchanged.

Surfaces that register a client can all set it:

  • The web "Register OAuth app" form: an optional "Extra token parameters" JSON field, prefilled by oauth.clients.createHandoff deep links.
  • oauth.clients.create and the createClient HTTP payload (via the new tokenParams).
  • Stored on oauth_client.token_params; corrupt stored values fail loudly (StorageError) on the same surfaces that already fail loudly for an unknown token-endpoint auth method.

Any name that would shadow an OAuth protocol parameter (grant_type, client_id, client_secret, scope, resource, code, code_verifier, redirect_uri, refresh_token) is rejected at registration and again before every token request, so a stored key can never override what the grant itself sends. First-party config (authorizationExtraParams), DCR-registered clients, and the oauth2 auth template stay on their existing paths.

Verification

  • bun run lint passes; new typecheck diagnostics match the pre-change baseline across packages/core/{sdk,api} and packages/react.
  • New tests: the three grants (client-credentials, authorization-code, refresh — form and JSON) send audience to a fixture token endpoint; a stored grant_type is refused before anything is sent; flow-level tests cover createClient(tokenParams) + oauth.start minting and the protocol-parameter rejection at registration; the executor-level mint sends the stored parameter; the form's parser accepts/prefills/rejects the JSON input.
  • vitest run: oauth-helpers 101 passed, oauth-flow 62 passed, executor 31 passed, packages/core/api 134 passed, oauth-client-form + add-account-modal 89 passed.

@Adityakk9031

Copy link
Copy Markdown
Contributor Author

GitHub's mergeability processor is wedged on the stale-update banner (the branch merges cleanly into main, verified with git merge-tree); reopening to reset it.

…oken-params

# Conflicts:
#	apps/cloud/drizzle/meta/0021_snapshot.json
#	apps/cloud/drizzle/meta/_journal.json

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[feature] Extra token request parameters for OAuth client credentials (Auth0 audience)

1 participant