Vercel Declares War on Long-Lived Static Credentials: How OIDC Is Reshaping Machine Identity Authentication

Title

Vercel Declares War on Long-Lived Static Credentials: How OIDC Is Reshaping Machine Identity Authentication

Meta Description

Vercel pushes OIDC to replace long-lived static credentials; a survey shows only 8.4% of SaaS vendors support secure authentication. Learn how OIDC works, Vercel's three-pronged strategy, and the 2026-2027 vendor deprecation timeline.

Article Content

Fifteen years ago, TLS was still just a means of protecting the most sensitive areas of an application. Then Google, Let's Encrypt, EFF, and others drove HTTPS to ubiquity, and encryption became the default for every request. Today, machine-to-machine authentication is at a similar turning point. Vercel recently announced that it will push OIDC (OpenID Connect) to become the default authentication method on its platform and across Marketplace integrations, and it has set a clear deprecation timeline for vendors that don't support secure authentication. This is not just a Vercel product decision—it may well be a signal of the entire industry migrating from static keys to dynamic identity tokens.

Why Long-Lived Static Credentials Are Unsustainable

Long-lived static credentials refer to secrets such as API keys and database passwords that applications reuse repeatedly, usually with no expiration time. Vercel points out in its post that as AI agents take on more and more work, we grant them permissions to access systems, tools, and data through credentials—permissions that often far exceed what the current task requires.

There are many paths to credential leakage: they may be committed to code repositories or chat logs, stolen when a service or dependency is compromised, or actively leaked by an agent due to prompt injection. Once leaked, an attacker can use the credential until it expires or is revoked. Vercel candidly admits that the company has spent thousands of engineering hours on key rotation out of caution multiple times, a painful process it never wants to repeat.

This leads to a key realization: static encryption is insufficient against credential theft in production environments. When malicious code can read an application's credentials in production, encrypted storage does not prevent them from being misused.

What OIDC Offers as an Alternative

The core idea of OIDC is to let applications authenticate without storing long-lived vendor keys. A trusted issuer provides signed, short-lived tokens to identify the application, and the receiving service verifies the token before deciding what permissions to grant.

This mechanism has two direct benefits. A stolen token becomes invalid after it expires, so even if a leak goes undetected, the attack window is limited to the token's validity period. At the same time, applications can obtain new credentials programmatically, eliminating the need to distribute and manually rotate persistent keys across every system that uses them.

Vercel already prioritizes OIDC support in services such as Blob, AI Gateway, and Sandbox. Its OIDC federation feature has been generally available since 2024, allowing applications running on Vercel to exchange Vercel-issued identity tokens for temporary credentials from AWS, Google Cloud, and Azure after a trust policy is configured for a project and environment. But for developers to truly move away from long-lived keys, this support must extend to all the services they depend on.

OIDC is built on the OAuth 2.0 authorization framework, and its core is the introduction of a standardized identity layer. In OAuth 2.0, the client obtains an access token, but the token itself contains no verifiable identity information; OIDC instead confirms the requester's identity through an ID Token (a signed JWT). The token is signed with a private key by a trusted issuer, and the recipient obtains the public key from the issuer's publicly available JWKS endpoint to verify the signature, without needing real-time communication with the issuer. The token typically contains claims such as iss (issuer), sub (subject identifier), aud (audience), and exp (expiration time), based on which the receiving service decides whether to trust the token and what permissions to grant. This verification model based on asymmetric signatures allows services to establish federated trust without sharing any long-lived keys.

In machine-to-machine scenarios, OIDC is often combined with the concept of "workload identity": a workload running on a cloud platform or in a CI/CD environment obtains a short-lived token from the platform as the issuer, and then proves its identity to the target service. This stands in sharp contrast to the traditional API key model—which is essentially a long-lived shared secret, and once leaked amounts to permanent authorization. The short validity period and audience restrictions of OIDC tokens limit the impact of a leak to a specific service and time window.

The Reality: Only 8.4% of SaaS Vendors Support Secure Authentication

Vercel surveyed more than 1,000 SaaS vendors and found that only 8.4% support secure authentication methods. This figure reveals the state of the industry: the standards already exist, but adoption is extremely low.

More challenging still, even when a service offers a secure method, developers often still choose static keys because they are simpler to use. Vercel identifies three main obstacles: tooling and setup make secure authentication more complex than using static keys; obtaining or exchanging tokens on the request path adds latency; and vendors lack the incentive to offer and prioritize secure authentication.

This is reminiscent of the state before HTTPS became ubiquitous—encryption was not technically infeasible, but the tooling wasn't good enough and the incentives weren't clear enough.

Vercel's Three-Pronged Strategy

Faced with these obstacles, Vercel is pushing forward in three directions simultaneously.

Lowering the barrier to use. On Vercel, code obtains an OIDC token through a function call and specifies the receiving service with a custom audience. Vercel Connect lets applications and agents request vendor tokens at runtime using their deployment identity, without storing long-lived keys in environment variables. Once a connector is configured and linked to a project and user account, code can request tokens within that user's permission scope. Vercel is also extending OIDC support to its API and CLI to eliminate the dependence on long-lived Vercel tokens in deployment workflows.

Providing out-of-the-box UI components. Vercel has launched OIDC UI, a shadcn/ui component registry that includes a trust policy configurator and a server-side token validator. It ships with built-in forms for Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure, and custom OIDC issuers. Vendors can let customers configure trust for the production environment of a specific Vercel project, then validate incoming tokens against that policy—without building the configuration interface and validation code from scratch.

Reducing performance overhead. Static keys sit in environment variables, and reading them requires no network request. Obtaining a token or exchanging credentials can add network latency, so reducing these calls is key to making secure authentication practical. Vercel Functions receive platform-issued tokens in the request headers, and the SDK reads them directly without an extra fetch; the platform reuses unexpired tokens, and Vercel Connect caches vendor tokens in-process and refreshes them as they near expiration. Only custom audiences and vendor exchanges require network calls. The post gives an example of using the Azure SDK to access Cosmos DB: exchanging a Vercel OIDC token for an Azure access token via ClientAssertionCredential, thereby avoiding the use of a database key.

A Hard Timeline for Vendors

The ubiquity of HTTPS was driven not only by ease of use, but also by Chrome's "Not Secure" label and deadlines. Vercel is replicating this strategy.

By November 30, 2026, vendors that do not support OIDC authentication from Vercel to their services and still use long-lived keys for authentication will see a similar "Not Secure" warning in their Marketplace listings. By January 2027, vendors that do not offer secure authentication will be delisted. Vercel says its own APIs and native integrations will also adhere to the same standard.

From Static to Dynamic: Vercel's Consistent Logic

Vercel describes this shift as a continuation of "from static to dynamic"—from static pages to dynamic pages, and now it's the turn of credentials. Fifteen years ago, encrypting every request seemed redundant; today, the padlock icon is so commonplace that it is only noticed when it's missing. Secure authentication between services should become just as ordinary.

It is worth considering whether Vercel's enforcement measures can truly drive the industry to follow suit. An adoption rate of 8.4% shows that the market is evolving too slowly on its own, and platform-imposed hard deadlines may be more effective than any technical evangelism. When Marketplace traffic and exposure are tied to authentication methods, vendors' incentive problem will be fundamentally changed. For developers, starting to migrate applications to OIDC flows now may be the most pragmatic preparation before the next round of platform rule changes.

Background

The key technology behind Vercel Connect is OIDC Federation. In the IAM systems of traditional cloud providers, federation allows tokens issued by an external identity provider (such as Vercel) to be trusted, thereby exchanging them for the cloud platform's own temporary security credentials. Taking AWS as an example, you need to configure the trust policy of an IAM Role, designate Vercel's OIDC issuer as a trusted principal, and restrict the aud and sub conditions; at runtime, the application uses the Vercel token to call the AWS STS AssumeRoleWithWebIdentity API and obtains temporary credentials typically valid for 15 minutes to 1 hour. Google Cloud's Workload Identity Federation and Azure's Federated Identity Credential follow similar logic. This mechanism eliminates the need to store cloud access keys long-term in environment variables, and also allows permission boundaries to be precisely controlled through trust policies.

Token caching and refresh design needs to strike a balance between security and performance. Short-lived tokens are typically valid for only a few minutes to an hour; if a token is re-obtained or exchanged on every request, the network round trips would significantly increase latency. A common practice is to maintain an in-process token cache that records the token's expiration time and refreshes it in advance when it nears expiration (for example, when less than 20% of the total lifetime remains), avoiding "token expired" failures on the request path. Refresh is usually done asynchronously in the background, without blocking requests being processed. At the same time, the cache needs to be bound to the token's audience and permission scope to prevent tokens from being misused between different services. Vercel's reuse of unexpired tokens in Functions and in-process caching of vendor tokens in Connect are exactly engineering implementations of this pattern.

One-line Summary

Vercel is pushing OIDC as the default authentication, replacing long-lived static keys with short-lived tokens and setting a vendor deprecation timeline.

Paragraph Summary

Vercel announced it is pushing OIDC to become the default authentication method on its platform and across Marketplace integrations, and has set a deprecation timeline for vendors that don't support secure authentication. The post notes that long-lived static credentials become increasingly risky in the era of AI agents, with many leakage paths and painful rotation, while OIDC provides short-lived signed tokens through trusted issuers, limiting the leak window and eliminating manual key distribution. Vercel surveyed more than 1,000 SaaS vendors and found only 8.4% support secure authentication, with the main obstacles being ease of use, latency, and insufficient vendor incentives. To address this, Vercel is pushing forward on three fronts: lowering the barrier (OIDC UI, Vercel Connect), reducing performance overhead (token caching, direct SDK reads), and vendor incentives (Marketplace "Not Secure" warnings and delisting), viewing this as a continuation of the shift from static to dynamic.