Vercel will require marketplace vendors to support OIDC

• Vercel will require Marketplace vendors to support OIDC, according to the rollout announcement, replacing persistent provider secrets with short-lived, identity-based access.
• Adoption is sparse: Vercel's survey found that only 8.4% of more than 1,000 SaaS vendors supported secure authentication methods.
• Providers get implementation help: the announcement includes a shadcn/ui registry for configuring trust policies and verifying tokens.
• Expiring tokens limit credential theft's persistence, but an attacker controlling the workload can still use its permissions, as a follow-up acknowledged.

Vercel Functions reuse identity tokens for up to 90 minutes, with a two-hour expiration. The new OIDC UI registry supplies server-side verification code alongside configuration forms. Vercel's agent infrastructure page pitches agents that investigate errors and open pull requests; its credential plan extends to the model, storage and sandbox services those workloads access.

Vercel's October 22 announcement sets two enforcement milestones:

• By November 30, 2026: Listings get a “Not secure” message if vendors lack OIDC authentication from Vercel and use long-lived secrets.
• By January 2027: Vendors that do not offer secure authentication will be delisted.

Delisting gives this push teeth.

Providers can accept OIDC tokens directly or exchange them for temporary credentials. Vercel says its API and native integrations will face the same standard, and it is working toward automatic authentication configuration when developers connect a Marketplace service.

Vercel attributes slow adoption to three barriers:

• More complicated setup than pasting a static key.
• Network latency from fetching or exchanging tokens.
• Weak incentives for vendors to prioritize secure authentication.

Elsewhere in agent marketplaces, jasonzhou1993 asked @bot's plugin marketplace team how to push plugin updates.

Providers get three pieces through OIDC UI:

• Trust-policy configurator: Customers can restrict trust to a particular Vercel project's production environment.
• Server-side verifier: Incoming tokens are checked against the configured policy.
• Issuer forms: Presets cover Vercel, GitHub, GitLab, Google, Bitbucket, AWS and Azure, plus custom OIDC issuers.

For developers operating their own issuer, cramforce described using a KMS for token issuance and serving the public key set from a web server. The receiving service still decides what access a verified identity receives.

Vercel is asking the industry to support machine identities; cramforce said the company was not moving into the identity space.

Vercel's federation has been generally available since 2024, and its documentation lists availability on all plans. Applications can exchange their deployment identity for temporary AWS, Google Cloud or Azure credentials under project and environment trust policies.

The runtime mechanics differ by surface:

• Builds: Vercel generates a token in VERCEL_OIDC_TOKEN.
• Functions: The platform supplies x-vercel-oidc-token in the request header, which the SDK reads without another fetch.
• Token lifetime: Function tokens last two hours and are reused for up to 90 minutes, leaving 30 minutes for execution.
• Exchanges: Custom-audience and provider exchanges still require network calls. Vercel Connect caches provider tokens in process and refreshes them near expiry.

Vercel's implementation examples also cover per-user access through Connect. Once a connector is configured, linked to the project and connected to the user's account, code can request provider-supported scopes:

The application uses its deployment identity to request that token without storing a long-lived provider secret in an environment variable. Vercel is also extending OIDC across its API and CLI to remove persistent Vercel tokens from deployment workflows.

BYOK tools could use trust policies instead of collecting customers' provider API keys under the arbitrary-issuer model raunakdoesdev proposed. Both major model providers document federation, with different issuer support:

• Anthropic: Its workload identity federation guide accepts any standards-compliant OIDC issuer. Anthropic checks the signed JWT against configured trust rules and returns a short-lived access token bound to a service account.
• OpenAI: Its federation guide tells API users to contact support for unlisted OIDC providers, reflecting the issuer restriction raunakdoesdev flagged. Codex separately offers a Custom OIDC option, with federation in beta and requiring workspace enablement.

An attacker who controls an authorized workload can continue exercising its access. Expiration limits how long an exfiltrated copy works, while the legitimate workload can obtain fresh credentials.

Old deployments also keep receiving new tokens, cramforce confirmed. Deployment reachability remains a separate control: Vercel warns when deployment protection is disabled, according to a follow-up.

Attackers are also targeting authorization flows. Reporting hundreds of different attempts each day, thdxr described a PlanetScale OAuth link configured to send credentials to an attacker.

Another attempt arrived through an enterprise contact form, using a complicated chain of links and exploits to target a locally running OpenCode server, thdxr said.