Vercel Passport is now generally available

Vercel Passport is now generally available.

Passport allows you to protect your Vercel deployments with your own identity provider. Visitors authenticate through Okta, Microsoft Entra ID, or any OIDC provider before viewing a protected deployment, and Vercel forwards a signed identity token to the deployment so application code can build on who the visitor is.

Read visitor identity in application code

The getIdentity() helper in @vercel/passport reads the Vercel request context and returns the authenticated visitor. Vercel strips client-supplied values for the x-vercel-oidc-passport-token header and injects the verified token after Passport validates the session, so the identity your code receives is already verified.

The subject field is a stable identifier for the visitor, scoped to your team and the Vercel Connect application that links Passport to your identity provider, and externalSubject is the visitor's ID in the provider itself. The helper returns null only when a request arrives without a Passport session, because unauthenticated browser visitors are redirected to the identity provider before they ever reach your code.

In local development, getIdentity() returns a configurable development identity, so the same code path works without a real identity provider.

Authorize with groups from your identity provider

The signed Passport token can now carry additional identity claims from your provider, such as group membership. Request the groups scope and allowlist the claim in the Vercel Connect application that Passport uses, then read it from the identity payload:

The additional identity scopes documentation covers provider configuration, including a full Okta walkthrough.

Verify identity in downstream services

Forward the Passport token from your application to another backend as a bearer token and verify it there with verifyIdentity(), available in @vercel/passport 1.0.0 and later. The helper checks the token signature, the Passport claims, and that the token came from the expected project and environment:

Services outside JavaScript can verify the token as a standard JWT with the published JWKS. Learn more in the verify identity documentation.

Monitor Passport access

Every successful Passport authentication records a passport-access-granted event in both the Activity Log and Audit Logs, identifying the visitor and recording the protected hostname and project. The Activity Log view is already filtered to Passport access.

Bypass Passport for automated traffic

Protection Bypass for Automation now applies to Passport. Webhooks, cron jobs, and CI runs that already send a bypass secret in the x-vercel-protection-bypass header or query parameter keep working when you turn Passport on. Because Passport runs in Vercel's network before your deployment's routes and proxy functions, the secret has to be part of the original request rather than added by your own middleware. A bypassed request has no signed-in visitor, so getIdentity() returns null.

Bypass Passport with Trusted Sources

Trusted Sources offers the same bypass without a shared secret. Protected deployments accept short-lived OIDC tokens from the Vercel projects and external services you authorize, which is how the workflow that triggers eve from Slack reaches a Passport-protected deployment.

Protect custom environments

Passport now supports custom environments, so deployments in an environment like staging or qa get the same identity provider sign-in as your preview and production deployments.

Get started

Vercel Passport is available on the Enterprise plan. New guides cover identity provider setup, token claims, local development, forwarding identity between backends, and bypassing Passport for automation.

Set up Passport with your identity provider in the Passport documentation, or configure it programmatically through the Vercel API.

Read more