Vercel wants static credentials gone. Its own GitHub Actions deploy still needs one

#oidc #secrets #vercel #githubactions

Count the long-lived tokens your deploy job can read right now. One is plenty, and a recent npm worm that scraped tokens straight out of CI pipelines made that point the expensive way. Vercel has now told its Marketplace vendors to get rid of theirs: they have until January 2027 to drop long-lived API keys or risk being delisted. Then developers opened Vercel's own GitHub Actions deployment guide.

The policy, and the stick behind it

Vercel CTO Malte Ubl says the company surveyed more than 1,000 SaaS vendors and found that only 8.4% supported what Vercel considers secure authentication methods. Vercel's proposed replacement is OpenID Connect (OIDC) plus short-lived, identity-based tokens, instead of API keys that can stay valid indefinitely. CEO Guillermo Rauch put it on X as "time to kill 'static credentials'", arguing that stolen credentials should behave more like "self-destructing keys" that expire before an attacker gets much use out of them.

There is a nearer deadline too. By November 30, Marketplace integrations that fall short of Vercel's authentication requirements get a "Not secure" warning on their listing.

Good policy, honestly. A platform using its distribution to force vendors off static keys will move more of them than a hundred conference talks. (Delisting tends to get a product manager's attention faster than a threat model does.)

Meanwhile, in the deploy guide

Vercel's GitHub Actions deployment guide still tells you to authenticate deployments with a VERCEL_TOKEN secret. Yordis Prieto, a senior software engineer at Fanatics, replied to the announcement that Vercel had "invented" OIDC federation yet still left him leaning on "a long-lived access token" in his CI pipeline. He also took aim at Vercel's non-expiring token option.

Vercel's answer is in Ubl's announcement: the company is extending OIDC support across its API and CLI to retire long-lived tokens from deployment workflows. It also added GitHub OIDC authentication for its Container Registry in late September. Neither change removes VERCEL_TOKEN from the documented GitHub Actions deploy flow today.

Hypocrisy? That's a cheap shot. Retrofitting OIDC into an existing API and CLI is the exact job Vercel is handing its vendors, and it isn't a weekend of work. Still, you don't get to sell the cure while your own install docs keep handing out the disease.

What federation does that a secret can't

If you haven't wired OIDC into a deploy job before, the general mechanism looks like this:

The CI job asks its platform's OIDC provider for a signed token. In GitHub Actions that requires permissions: id-token: write on the job.
The token carries claims about where the job runs: repository, ref, workflow, environment.
The target service checks the signature against the issuer's public keys, checks the audience, and matches the claims against a trust policy you wrote.
If everything matches, the service issues its own short-lived credential. It expires on its own, and nothing sits in your repository settings waiting to leak.

So the trust boundary moves. The question used to be "who can read this secret?" and becomes "who can get a workflow to run that matches this policy?" That's a better question, but it doesn't answer itself. Write a subject match loose enough to accept any branch or any repo in the org, and anyone who can push a workflow file can mint deploy credentials. Same blast radius, fresher paperwork. Pin the trust policy to one repository and one protected branch or environment. (We covered a similar fine-print problem when npm trusted publishing gained dist-tag support.)

Living with VERCEL_TOKEN until the CLI catches up

You can't federate a deploy that only takes a token. You can make the token less attractive to steal:

Give it an expiry. Skip the non-expiring option Prieto complained about.
Put it in a GitHub environment with protection rules, and reference that environment only from the deploy job.
Keep it out of any job that runs on pull requests from forks.
Rotate it on a schedule, and immediately after anything that smells like a leak.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # VERCEL_TOKEN lives here, behind required reviewers
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<full-40-char-sha>
      - run: npx vercel deploy --prod --token="$VERCEL_TOKEN"
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

The fine print nobody published

Vercel hasn't published the survey methodology, named the companies it surveyed, or said how many existing Marketplace partners will have to change their authentication. Keep that in mind before you quote 8.4% at your vendor-review meeting.

Then there's Vercel Connect, which lets applications and agents request scoped credentials at runtime using their deployment identity and handles token exchange and renewal. It still supports static API keys for providers that lack OAuth or another identity-based option. Its documentation describes storing those keys centrally and pulling them at runtime, and the keys underneath can still live indefinitely. A static key in a central vault is still a static key. It just has a nicer address.

Until the CLI speaks OIDC, the most dangerous string in your Vercel deploy is the one Vercel's guide tells you to paste in. Vercel just gave its vendors an expiry date. Give your token one too.

DEV Community