For Service Providers

If you are a service owner, this page covers what your service needs to support so Vercel Connect can discover, register, and authorize against it using standard OAuth. It applies to any OAuth-protected API, authorization server, or Model Context Protocol (MCP) server.

A Vercel team creates a connector that points at your service, by name or by URL. Vercel Connect then:

1. Reads your OAuth and OpenID Connect discovery documents to find your endpoints and capabilities.
2. Creates an OAuth client by registering it with dynamic client registration (DCR) or by publishing a client ID metadata document (CIMD), or connects one using the credentials your user provides.
3. Runs your authorization or token flow, then stores and refreshes the tokens.
4. Hands short-lived tokens to your user's code at runtime.

How much your users configure by hand depends on what your service supports:

Publish authorization server metadata under RFC 8414, an OpenID Connect discovery document, or both. Most of the requirements on this page are fields in one of them.

Vercel Connect checks the standard well-known locations. If your server URL has a path, such as https://auth.example.com/tenant1, it also checks the path-suffixed form from RFC 8414 Section 3.1, so multi-tenant servers work either way. Serve the documents as application/json.

If you serve both documents, Vercel Connect fills gaps in the OAuth one from the OpenID Connect one. Both need to declare the same issuer and token_endpoint.

Vercel Connect reads these fields:

Vercel Connect reads grant_types_supported to work out what a connector can do. Each grant maps to a token subject type:

A grant you leave out never shows up as a capability.

Vercel Connect uses this redirect URL: https://connect.vercel.com/callback

Accept it through DCR or CIMD, or let your users configure it themselves when they register an application. It needs an exact match, so no wildcard support is required.

RFC 6749 makes expires_in optional. However, without it, Vercel Connect infers a lifetime, and your API can end up receiving requests with expired tokens.

Vercel Connect supports two standard ways to create a client, so users don't register an application at all. It detects both from your discovery documents.

Dynamic client registration (RFC 7591). Declare a registration_endpoint. Vercel Connect authenticates the client with client_secret_basic, client_secret_post, none, or private_key_jwt. If your token_endpoint_auth_methods_supported doesn't include one of these, Vercel Connect won't perform DCR.

Client ID metadata documents. Declare client_id_metadata_document_supported: true. Vercel Connect uses CIMD when you support private_key_jwt, or when you support public clients and declare S256 in code_challenge_methods_supported. Your server reads the client metadata from a URL Vercel hosts, so there's no registration call, and an edit to a connector reaches you the next time you read it.

Either way, Vercel Connect sends this client metadata:

For private_key_jwt, Vercel Connect signs client assertions with a per-connector key and publishes the public key at jwks_uri. Fetch the key set from there instead of asking for a static upload, so key rotation doesn't break existing connectors. Vercel Connect uses RS256 unless your token_endpoint_auth_signing_alg_values_supported names another supported algorithm.

Support RFC 7592 and return registration_access_token and registration_client_uri from registration. Vercel Connect uses it to keep a DCR-created client in sync when your user renames a connector, changes its icon, or enables another grant type.

CIMD needs nothing here. You read the metadata document, so it's already current.

Declare S256 in code_challenge_methods_supported. When declared, Vercel Connect uses Proof Key for Code Exchange (PKCE) in authorization flows per RFC 9700. It's also one of the two paths to CIMD for public clients.

Declare refresh_token in grant_types_supported and issue refresh tokens on the authorization code flow. Without them, every expiry sends your user through an authorization prompt again. If you rotate refresh tokens, return the new one in every refresh response.

If your service is an MCP server, or any other protected resource in front of a separate authorization server, publish RFC 9728 protected resource metadata with a non-empty authorization_servers array. Your users can then point Vercel Connect at the resource URL they already know, instead of looking up an authorization server URL.

Declare a revocation_endpoint per RFC 7009. Vercel Connect then offers revocation in the dashboard, the CLI, and the SDK, and calls your endpoint when your user revokes a token.

Vercel Connect also revokes the tokens it holds when your user removes an installation or deletes a connector, and calls your revocation_endpoint if you declare one. Without one, revoking only removes Vercel's stored copy, and your side treats the token as live until it expires.

List every scope a client can request in scopes_supported. Vercel Connect offers this set to your users when they configure your OAuth client in the Vercel dashboard or CLI.

If you serve OpenID Connect, include openid, plus profile and email where you support them. Vercel Connect shows those separately from your API scopes.

Two specifications let your users ask for narrower tokens. Vercel Connect passes both through:

• RFC 8707 Resource Indicators: accept the resource parameter, so a token only works against the API your user named.
• RFC 9396 Rich Authorization Requests: declare your types in authorization_details_types_supported, and Vercel Connect offers them on the connector.

Accept logo_uri in client metadata, so your consent screen shows the application your user is authorizing instead of a placeholder.

Check what Vercel Connect can see about your service in two steps.

First, review your discovery document:

curl -sS https://auth.example.com/.well-known/oauth-authorization-server | jq '{
  issuer,
  authorization_endpoint,
  token_endpoint,
  registration_endpoint,
  revocation_endpoint,
  grant_types_supported,
  token_endpoint_auth_methods_supported,
  code_challenge_methods_supported,
  client_id_metadata_document_supported,
  scopes_supported
}'

Then create a connector against your own service with the Vercel CLI:

vercel connect create auth.example.com

The CLI discovers your well-known endpoints and will automatically register the client if you support DCR/CIMD.

Use Submit a Service to describe your service, test it with Vercel Connect, and send it to Vercel for review.

The Submit a Service page uses these terms:

To submit your service:

1. Open Submit a Service in the Vercel dashboard. It's also linked from your team's Connect > Browse Connectors page. You need permission to create connectors in the team.
2. Enter your Service Name, upload an optional SVG icon, and complete Service Information.
3. Optionally, add Targets.
4. In Connection Methods, select Add OAuth or Add API Key, then configure the method.
5. Test each OAuth method.
6. Select Review Submission, check the configuration, then select Submit for Review.

Only OAuth methods need a test. Vercel checks the test on its servers when you submit, so the test connector and its token must still exist in your team.

To test an OAuth method with a real token:

1. Open the OAuth method and select Preview & Test. If you entered a Server URL, discovery runs automatically.
2. Select Set Up Test Connector. How you create the OAuth client depends on Automatic Registration:
   • On: Vercel Connect registers the client through DCR or CIMD. You only need a connector name.
   • Off, or endpoints entered manually: register an application with your service using the redirect URL https://connect.vercel.com/callback, then enter its client ID, plus a client secret if your service issues one. The draft doesn't save these credentials.
3. Select Create Test Connector. The connector appears under Test Connectors and is selected for submission.
4. Select Test User Token to authorize as a user in a popup, or Test App Token to use client credentials. Keep the method's default scopes selected.
5. When the connector shows Token retrieved, the method is ready to submit.

The Automatic Registration toggle appears only when your discovery documents advertise DCR or CIMD, and it's on by default. Test with it on to prove automatic registration works, or turn it off to submit manual setup only.

If your endpoints use URL placeholders, such as {tenant}, the test connector uses each field's Value for Testing.

A token test only counts for the exact configuration it tested. Create a new test connector and test a token again after you:

• Change the method's URLs, OAuth settings, template fields, or Automatic Registration. Older connectors then show Earlier configuration.
• Edit or delete the test connector.
• Change your discovery documents.

• The page shows Service Submitted, a submission ID, and each method's status.
• Vercel reviews your submission and publishes your service. If Vercel needs more details, it contacts you at your Contact Email.
• To make changes, select Edit and Resubmit.
• Test connectors stay in your team. Reset Draft clears the browser draft but doesn't delete them.

• Connectors: the record your users work with when they connect to your service.
• Tokens: subject types, scopes, refresh, and revocation as your users see them.
• Authentication: how Vercel Connect proves identity in both directions.