OIDC in Simple Terms | Nic's notes

Table of Contents

The problem: keys that never expire
The idea, in simple terms
What's inside a token
Where it came from
What Vercel is doing
- The deadline
Why it matters for AI agents
Limits
Further Reading

OIDC (OpenID Connect) is a standard way for one system to prove who it is to another, with a short-lived, signed token instead of a password or a permanent API key. You already use it every time you click "Sign in with Google". The same idea now replaces the API keys that apps, build pipelines and AI agents keep in config files.

Vercel made the case in Death to long-lived static credentials: machine-to-machine authentication today looks like the web before HTTPS everywhere, and Vercel wants to make the secure option the default.

The problem: keys that never expire

A long-lived static credential is a secret that an app reuses for months or years: an API key, a database password, a cloud access key. It usually sits in an environment variable or a .env file, and it often has no expiry date.

That key leaks in ordinary ways:

Committed to a code repository or pasted into a chat.
Stolen when a dependency or a service is compromised.
Revealed by an AI agent after a prompt injection asks it to print its environment.

Whoever has the key can use it, with all its permissions, until someone notices and revokes it. Rotating it is painful: Vercel says it spent 1,000s of engineering hours on key rotations it never wants to repeat. And as agents get more work, they also get more keys, often with far more permissions than the task needs.

The idea, in simple terms

Think of a hotel key card instead of a house key.

A house key works forever, for anyone who holds it. Copy it once and the copy works too.
A hotel key card is issued at the desk after you prove who you are. It opens 1 room, and stops working at checkout.

OIDC is the hotel key card for software:

A trusted issuer vouches for the app. The platform the code runs on (Vercel, GitHub Actions, Google Cloud, AWS) knows exactly which project, branch and environment is running. It issues a token that says so, signed with its private key.
The token is short-lived. It expires in minutes or hours, not years.
The receiving service checks the signature with the issuer's public key, then checks the details in the token against a trust policy: "accept tokens from Vercel, for project X, production environment only".
If it matches, access is granted, often as temporary credentials of its own.

Nothing permanent is stored in the app. There is no key to leak, and a stolen token is worthless once it expires.

What's inside a token

An OIDC token is a JWT (JSON Web Token): a small signed JSON document. The fields that matter:

Claim	Meaning	Example
`iss`	Issuer: who signed the token	Vercel, GitHub Actions
`sub`	Subject: who the token is about	A project and environment, a repo and branch
`aud`	Audience: which service should accept it	The one API meant to receive it
`exp`	Expiry time	Minutes or hours after issue

The audience matters. Vercel's custom audiences scope each token to the one service meant to receive it, so a token stolen from one service can't be replayed against another.

Where it came from

OAuth 2.0 (2012) is the standard for authorisation: "this app may read your calendar".
OpenID Connect 1.0 (2014), from the OpenID Foundation, adds an identity layer on top: "and this is who the user is". That is the login part, as in "Sign in with Google".
Workload identity is the later use: the same signed tokens, but issued to machines instead of people. GitHub Actions, the big clouds and now Vercel use it so that pipelines and apps can reach each other without stored keys.

What Vercel is doing

From Vercel's post:

OIDC federation, generally available since 2024: apps on Vercel swap Vercel-issued tokens for temporary AWS, Google Cloud and Azure credentials.
Vercel's own services (Blob, AI Gateway, Sandbox) accept OIDC, so apps don't need stored keys for them.
Vercel Connect: apps and agents use their deployment identity to request provider tokens at runtime, such as read-only access to Linear for 1 user, without storing secrets in environment variables.
OIDC UI: a shadcn/ui registry that gives API providers ready-made trust-policy forms and token-verification code, for Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure and custom issuers.
Speed: Vercel Functions receive a token in the request header, and tokens are cached and reused, so security doesn't cost a network call on every request.

import { getToken } from '@vercel/connect';

// Ask for a short-lived, read-only Linear token for 1 user, at runtime
const token = await getToken('oauth/linear', {
  subject: { type: 'user', id: 'user_123' },
  scopes: ['read'],
});

The deadline

Vercel surveyed more than 1,000 SaaS vendors and found that only 8.4% supported secure authentication methods. So it copies what Chrome did to plain HTTP:

By 30th November 2026: Marketplace vendors without OIDC support get a "Not secure" label on their listing.
By January 2027: vendors who still don't offer secure authentication are delisted.

Vercel holds its own API and native integrations to the same rule.

Why it matters for AI agents

An agent is code that acts with whatever credentials it can reach. With static keys, a single prompt injection or a leaked log can hand an attacker a key that works for years. OIDC changes 3 things:

Nothing to steal at rest. The agent asks for a token when it needs one, instead of reading a key from a file.
Small blast radius. Each token is limited to 1 service (the audience), 1 task (the scopes) and a short time (the expiry).
Identity per deployment. The token says which project and environment asked, so a provider can trust production and refuse everything else.

It pairs with a hardware key such as the YubiKey: OIDC removes standing secrets from machines, and the YubiKey protects the human accounts that configure the trust policies, see YubiKey 5C NFC.

The catch for a personal setup: most tools still only accept a static API key, so a .env file stays the reality for many services. The practical rule until then: one key per tool, the narrowest scope the service allows, an expiry date where it's offered, and never a key an agent can print into a log.

Limits

Both sides must support it. The service you call has to accept OIDC tokens or exchange them, and only 8.4% of the vendors Vercel surveyed do.
Setup is harder than pasting a key: a trust policy, an audience, sometimes a token exchange. Vercel's tooling exists to close that gap.
The trust policy is the new secret. A policy that accepts any branch or any project gives the same broad access as a leaked key. Pin it to the project, environment and branch that need it.
It doesn't protect a running process. Code that is compromised while it runs can still use the token it holds, for as long as it lives.