OpenID Connect: Short-Lived Tokens for Service-to-Service Auth

OpenID Connect (OIDC), introduced by the OpenID Foundation in 2014, was originally designed to simplify user authentication. Built as an extension of OAuth 2.0, it layers identity verification on top of authorization capabilities. But the protocol is equally valuable for authenticating services to each other, replacing static secrets with a trust model where the caller's identity is verified via tokens rather than shared credentials.

Vercel now supports OIDC Federation for this purpose. Developers can replace long-lived credentials in environment variables with short-lived, RSA-signed JSON Web Tokens (JWTs) for external requests in both builds and Vercel Functions.

OIDC works by establishing a trust relationship between an identity provider (IdP) and the services that need mutual authentication. When one service calls another, it presents an OIDC token identifying the caller. The receiving service verifies that token and decides whether to accept the call based on the caller's identity.

This approach eliminates static secrets that can be leaked or lost. The security benefits are twofold:

  • Reduced risk: No static credentials exist to be compromised, and tokens expire quickly.
  • Lower operational burden: Token issuance and rotation happen automatically.
Long-lived credentials increase risk over time, while short-lived tokens are only created as-needed and expire, effectively minimizing associated risks.

Vercel as an Identity Provider

With OIDC enabled, Vercel acts as the IdP. When a request reaches compute (Vercel Functions), it is enriched with a pre-signed OIDC token that third parties can verify. The token is an RSA-signed JWT containing claims that identify the Vercel account, including the environment, project, and owner, along with an expiration (exp) timestamp.

The token itself is Base64 encoded but not encrypted and can be inspected with jwt.io's debugger.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Im1yay00MzAyZWMxYjY3MGY0OGE5OGFkNjFkYWRlNGEyM2JlNyJ9.eyJpc3MiOiI8aHR0cHM6Ly9vaWRjLnZlcmNlbC5jb20-Iiwic3ViIjoib3duZXI6bWFyYy1ncmVlbnN0b2Nrcy1wcm9qZWN0czpwcm9qZWN0Om9pZGMtZGVtbzplbnZpcm9ubWVudDpkZXZlbG9wbWVudCIsInNjb3BlIjoib3duZXI6bWFyYy1ncmVlbnN0b2Nrcy1wcm9qZWN0czpwcm9qZWN0Om9pZGMtZGVtbzplbnZpcm9ubWVudDpkZXZlbG9wbWVudCIsImF1ZCI6IjxodHRwczovL3ZlcmNlbC5jb20vbWFyYy1ncmVlbnN0b2Nrcy1wcm9qZWN0cz4iLCJvd25lcl90eXBlIjoidGVhbSIsIm93bmVyIjoibWFyYy1ncmVlbnN0b2Nrcy1wcm9qZWN0cyIsIm93bmVyX2lkIjoidGVhbV9BMWIyQzNkNEU1RjZnN0g4aTlKMGtMbU4iLCJwcm9qZWN0Ijoib2lkYy1kZW1vIiwicHJvamVjdF9pZCI6InByal9LMkZuVDl5WnhWNkh3UXBMME84UjNzUGRXYzdYIiwiZW52aXJvbm1lbnQiOiJkZXZlbG9wbWVudCIsIm5iZiI6MTcyMzA5ODY5OCwiaWF0IjoxNzIzMDk4Njk4LCJleHAiOjE3MjMxNDE4OTh9.J3XFGWdHdOhnk-nbHKYWz-Aa7fT02RBzTBoGK4zSzeLh_AyMGqGqVknhudedF13sqLKHHvZoo77cryijNAg11V_jyayYsTos7KHuLX9qIjMqlKEC7Fin76z6l3qG6sj-X_JrKTCe_4wpWrIYycK2Tz01XXt2NnWEqfChyQ46n05G0e8WjT3EbL8euxhokQemrNnQLRD1gcsAQ-3_VZZ8CWZ0L5OGFyFT9qaj2cCrm_Pli1uIPpSyyZRzzvM7-X41_w1ajvvoJwSgi8JDqMfRa41Y-ipGFoR-gGAa5cxf1xeXh3W5woz7RexbYPSvrIAcnJUDvofnrdXdbYLjdWM5DQ

Vercel's OIDC provider is recognized by major platforms including AWS, Azure, Firebase, and GCP. This interoperability lets developers manage authentication across their infrastructure with a single, consistent framework.

Comparing Two Authentication Approaches

Consider a typical setup where a developer connects an application to AWS S3 by storing credentials like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in a .env file:

AWS_ACCESS_KEY_ID=AWSKEYEXAMPLE
AWS_SECRET_ACCESS_KEY=AWSSECRETACCESSKEYEXAMPLE

These static environment variables are used throughout the application to authenticate against S3. The risk: credentials may not be rotated regularly, and if an attacker obtains them, they can access sensitive data indefinitely until the breach is detected and credentials are manually revoked.

Without OIDC, credentials are typically hard-coded and stored in environment variables, remaining static and reused until manually rotated.

The OIDC alternative

With OIDC, the developer enables the feature in the Vercel project's security settings and uses the @vercel/functions package to fetch AWS credentials dynamically:

import { awsCredentialsProvider } from '@vercel/functions/oidc';
import * as s3 from '@aws-sdk/client-s3';
const s3client = new s3.S3Client({
  credentials: awsCredentialsProvider({
    roleArn: process.env.AWS_ROLE_ARN!,
  }),
});

Whenever the application needs to perform an operation on S3, it requests temporary credentials from Vercel's OIDC provider. The awsCredentialsProvider function receives the Vercel-issued OIDC token and obtains short-lived credentials using the role ARN from the environment variable, allowing the application to assume a specific role with limited permissions. The credentials are specific to the operation and expire quickly, minimizing the impact of any compromise.

Both scenarios make identical API calls to AWS, but only the OIDC approach avoids long-lived secrets.

How Token Exchange Works

Within a Vercel Function, the awsCredentialProvider function from @vercel/functions/oidc handles the token exchange automatically. It invokes AWS's AssumeRoleWithWebIdentity operation, which returns temporary security credentials for users authenticated with a web identity provider. The exchanged token is created on demand, expires shortly, and the only credential stored in the application is the role that needs to be assumed.

This approach aligns with modern authentication best practices, supporting consistent role-based access control by managing roles instead of credentials. It also reduces the compliance burden, since credential rotation is handled automatically.

Vercel's OIDC support is complemented by Secure Compute, which lets organizations establish secure perimeters between the Vercel Edge Network and backend systems. Together, they provide a framework for securing backend connectivity without static credentials.