Vercel 11 月 30 日「Not secure」標籤：Marketplace API 供應商需要建置甚麼

On November 30, 2026, Vercel starts labeling some Marketplace vendors "Not secure." If your API still asks Vercel customers to paste a long-lived API key into an environment variable, that label is aimed at you.

Here's what the change says, what your options are, and what an OIDC token exchange looks like.

What Vercel announced

In Death to long-lived static credentials (Oct 22, 2026), Vercel set two dates:

• By November 30, 2026: vendors that don't support OIDC auth from Vercel and authenticate with long-lived secrets get a "Not secure" label in the Marketplace.
• By January 2027: vendors without secure auth are removed from the Marketplace.

Vercel says it surveyed more than 1,000 SaaS vendors and found only 8.4% support a secure, short-lived auth method. Most of the long tail is starting from zero.

The reasoning is the same as Chrome's "Not secure" label for plain HTTP, which Vercel compares it to directly. A static key in an env var doesn't expire on its own and is only as safe as the least careful place it was pasted.

What "support OIDC" means in practice

Vercel deployments can get a signed OIDC token (a JWT) that identifies which team, project and environment is calling. Your API needs to trust that token instead of a stored secret. The flow:

1. Your customer sets a trust policy in your dashboard, e.g. "allow tokens from issuer X, audience Y, for this project's production environment."
2. The workload calls your token endpoint with its OIDC token.
3. You verify it: check the signature against the issuer's public keys (JWKS), check exp, then match iss exactly and the claims (aud, project, environment) against the stored policy.
4. You map it to permissions the customer already has, typically the scopes of an existing API key or account.
5. You return a short-lived token of your own (minutes, not months). Your existing API then accepts that token like any other credential. This pattern is standardized as OAuth 2.0 Token Exchange (RFC 8693).
6. You keep an audit log and a revoke button, because "which workload called us, under which policy" is now the question security teams ask.

Your options

1. Build it yourself. Vercel published free OIDC UI components, built on shadcn/ui: provider forms for Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure and custom issuers, plus a server-side token verifier. They give you steps 1 and 3. The docs are explicit that the form emits a policy object and you persist it. Steps 4–6 are still yours: storage, mapping to your key and permission model, issuing your own short-lived token, revocation, audit and docs. For a small team that's real work, but well understood.

2. Use an identity provider. If your API's identities already live in an IdP that supports token exchange, it can do most of this for you. For example, Auth0 announced Custom Token Exchange as generally available on Oct 16, 2026. Check which plan includes it: on Auth0's pricing page it appears under B2B Professional, listed from $800/month. That makes sense if you're already there. It's a big move if your keys live in your own Postgres table.

3. Wait. One write-up of the change notes that OIDC support is self-reported by vendors for now, and deadlines sometimes slip. But the label is public-facing, and buyers with a "no static secrets" policy were asking for this before Vercel did. In the LiteLLM project, someone requesting OIDC support described it as "increasingly table stakes" for SOC 2 / ISO 27001 / FedRAMP shops.

A minimal checklist

• Expose a token endpoint that accepts a Vercel OIDC JWT.
• Require an aud rule in every policy; match iss exactly (OIDC UI enforces both).
• Keep issued tokens short-lived; never mint something longer-lived than the key you're replacing.
• Map to existing scopes; don't invent a second permission model.
• Log every exchange (policy id, subject, project, environment).
• Write a "connect without a key" page in your docs. Your customers need it as much as your code does.

This article was drafted with AI assistance and fact-checked against the linked sources.