TLS once protected only an application's most sensitive corners. A sustained push by Google, Let's Encrypt, the EFF and others made HTTPS the default for every request, so today a missing padlock is the anomaly. OAuth, OIDC, DBSC and similar standards already supply the pieces for secure authentication, but standards alone don't change habits. Machine-to-machine authentication largely still sits where HTTPS was in 2010: some vendors lead, while long-lived static credentials remain the default for many SaaS and infrastructure providers.

Vercel is extending OIDC support across its platform, requiring OIDC for Marketplace providers and shipping OIDC UI, a shadcn/ui registry that hands providers trust-policy forms and token verification code.

Why static keys fail

Long-lived static credentials — API keys, database passwords — are reused by applications, often without expiration. They leak into repositories or chat, get stolen when a service or dependency is compromised, or surface via prompt injection that leads an agent to reveal them. Whoever captures one keeps its permissions until it expires or is revoked. Encryption at rest offers little defense when malicious code can read an application's credentials in production.

Rotation is slow, spans every system consuming the credential, and a mistake can break production. Vercel has spent thousands of engineering hours on multiple painful rotations out of caution.

OIDC as the replacement

Under OIDC a trusted issuer signs a short-lived token identifying the application, and the receiving service verifies it before granting access. No provider key is stored. A stolen token dies with its expiry, and fresh credentials are obtained programmatically, so there is nothing to distribute or rotate by hand.

import { getToken } from '@vercel/connect';
const token = await getToken('oauth/linear', {
  subject: { type: 'user', id: 'user_123' },
  scopes: ['read'],
});

Vercel already uses OIDC so applications can reach Blob, AI Gateway and Sandbox without persistent keys. OIDC federation has been generally available since 2024, exchanging Vercel-issued identity tokens for temporary AWS, Google Cloud and Azure credentials governed by project and environment trust policies.

OIDC UI builder with identity provider, form library, and verifier options on the left and a Vercel trust-policy form preview on the right.

The adoption problem

In a survey of more than 1,000 SaaS vendors, only 8.4% supported secure authentication methods. Even where a secure path exists, developers often pick a static key because it is simpler. Vercel identifies three barriers:

  • Tooling and setup that make secure authentication harder than a static key.
  • Latency from fetching or exchanging tokens on the request path.
  • Weak incentives for vendors to prioritize secure authentication.

Making tokens easier than pasted keys

In Vercel code, an OIDC token comes from a function call, and a custom audience scopes it to the service meant to receive it. Vercel Connect lets applications and agents request provider tokens at runtime using their deployment identity, so no provider secrets live in environment variables. Once a connector is configured and linked to a project and the user's account is connected, code can request a user-scoped token with whatever scopes the provider supports. OIDC support is also spreading across the Vercel API and CLI to eliminate long-lived Vercel tokens in deployment workflows.

Sharing the plumbing with providers

OIDC UI pairs a trust-policy configurator with a server-side token verifier. Its provider forms cover Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure and custom OIDC issuers, so a provider can let customers trust a specific Vercel project's production environment and validate incoming tokens without building the interface or verification logic itself.

OIDC UI builder with identity provider, form library, and verifier options on the left and a Vercel trust-policy form preview on the right.
OIDC UI builder with identity provider, form library, and verifier options on the left and a Vercel trust-policy form preview on the right.
OIDC UI builder with identity provider, form library, and verifier options on the left and a Vercel trust-policy form preview on the right.

Keeping latency down

An environment-variable key is present the moment a function runs; fetching a token or exchanging it for provider credentials adds network calls. Vercel Functions receive a platform-issued token in the request header that the SDK reads without fetching elsewhere, and the platform reuses unexpired tokens. Vercel Connect caches provider tokens in process and refreshes them near expiry. Custom-audience and provider exchanges still require network calls.

With Azure trusting a Vercel project and its default token audience, a callback can hand a Vercel OIDC token to ClientAssertionCredential, which swaps it for the Azure access token CosmosClient uses — avoiding a database key stored in the app.

import { getVercelOidcToken } from '@vercel/oidc';
import { ClientAssertionCredential } from '@azure/identity';
import { CosmosClient } from '@azure/cosmos';
const credentialsProvider = new ClientAssertionCredential(
  process.env.AZURE_TENANT_ID!,
  process.env.AZURE_CLIENT_ID!,
  () => getVercelOidcToken(),
);
const cosmosClient = new CosmosClient({
  endpoint: process.env.COSMOS_DB_ENDPOINT!,
  aadCredentials: credentialsProvider,
});

Marketplace requirements and deadlines

Vercel aims for every Marketplace vendor — databases, CMSs, observability tools and others — to accept short-lived, identity-based authentication, directly via OIDC or through exchange for temporary credentials, with integrations configuring it automatically on connection rather than as a separate setup step.

The deadlines are explicit: by November 30, 2026, vendors that lack OIDC auth from Vercel and rely on long-lived secrets will carry a "Not secure" notice on their listing; by January 2027, vendors without secure auth will be delisted. The Vercel API and Vercel's native integrations are held to the same standard.