Vercel wants long-lived static credentials gone and is shipping OIDC tooling to do it

Vercel has published a broad argument for eliminating long-lived static credentials, comparing machine-to-machine authentication today to the state of web encryption in 2010, and it is backing the argument with product changes across its own platform, new tooling for API providers, and stricter authentication requirements for Marketplace integrations.

The argument

In a blog post, Vercel draws a parallel with the campaign for HTTPS everywhere, which Google, Let's Encrypt, the EFF and others drove from a niche protection for sensitive pages to the default for every request. Standards such as OAuth and OIDC already provide the building blocks for secure machine-to-machine authentication, the company argues, but standards alone did not make encryption normal; tooling that made it easy and sustained pressure that made it expected did.

Long-lived static credentials, meaning API keys and database passwords that applications reuse, frequently with no expiration, remain the default at many SaaS vendors and infrastructure providers. Vercel identifies several ways they fail: keys leak into repositories or chats, they get stolen when a service or dependency is compromised, and, increasingly, they can be exposed when prompt injection tricks an AI agent into revealing them. Whatever the route, an attacker retains the credential's permissions until it expires or someone revokes it. Vercel adds that it has previously spent thousands of engineering hours on precautionary key rotations and never wants to repeat the exercise.

The alternative on offer is OIDC federation: a trusted issuer hands the application a signed, short-lived token, and the receiving service verifies that token before deciding what access to grant. A stolen token stops working on its own when it expires, and applications fetch fresh credentials programmatically rather than distributing and manually rotating a persistent key. According to Vercel, its OIDC federation has been generally available since 2024, letting applications running on the platform exchange Vercel-issued identity tokens for temporary AWS, Google Cloud and Azure credentials under project- and environment-scoped trust policies.

What Vercel is shipping

The post announces several concrete pieces:

• Vercel Connect, through which applications and agents use their deployment identity to request provider tokens at runtime, so long-lived provider secrets no longer sit in environment variables.
• OIDC UI, a shadcn/ui component registry containing a trust-policy configurator and a server-side token verifier, with provider forms covering Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure and custom OIDC issuers. The intent is that a provider can let customers configure trust for a specific Vercel project environment and verify incoming tokens without building that machinery itself.
• Expanded OIDC support across Vercel's own services, including Blob, AI Gateway and Sandbox, plus the Vercel API and CLI, which would remove long-lived Vercel tokens from deployment workflows.

The adoption gap

According to a Vercel survey of more than 1,000 SaaS vendors, only 8.4% supported secure authentication methods. The company attributes the slow uptake to three barriers: tooling and setup that make secure authentication more complicated than pasting a static key, added latency from fetching or exchanging tokens on the request path, and weak incentives for vendors to offer and prioritize it.

On latency, Vercel says Vercel Functions receive a platform-issued token in the request header that the SDK reads without an extra network call, that unexpired tokens are reused, and that Vercel Connect caches provider tokens in process and refreshes them near expiry. Custom-audience and provider exchanges still require network calls. As an illustration, the post shows an application reaching Azure Cosmos DB with temporary credentials by feeding a Vercel OIDC token into Azure's ClientAssertionCredential instead of storing a database key.

Vercel also plans to use its Marketplace as leverage, setting new authentication requirements for providers and working toward integrations that configure identity-based authentication automatically when a developer connects a service, rather than as a separate setup step.

Why it matters

The HTTPS comparison is the substance of the claim, not just rhetoric. If the analogy holds, deployment pipelines and third-party integrations built on environment-variable API keys are the new plain HTTP: functional today, but on a path to being treated as a legacy liability. Teams running CI/CD and agent-driven workflows should expect a gradual shift toward short-lived federated tokens, and vendors that only offer static keys may find themselves gated out of marketplaces like Vercel's. AI agents raise the stakes further, since credentials handed to agents often carry permissions far beyond the task at hand and can be spilled through prompt injection, making automatic expiry a meaningful defense rather than a nicety. The 8.4% figure shows how much of the ecosystem still has to move for that shift to actually happen.