Vercel Passport chega ao GA e coloca seu provedor de identidade na frente do deploy

Todo mundo que faz deploy na Vercel já topou com a tela de senha compartilhada do Deployment Protection. Funciona, mas é fricção: senha por Slack, ninguém sabe quem acessou o preview, e nada de autorização por perfil. O Vercel Passport, agora em disponibilidade geral (GA), resolve isso conectando a proteção do deployment ao seu próprio provedor de identidade.

O que é, na prática

O Passport intercepta o acesso a um deployment protegido antes de a requisição chegar às suas rotas. O visitante autentica via Okta, Microsoft Entra ID ou qualquer provedor OIDC, e a Vercel encaminha um token de identidade assinado para a aplicação. Ou seja: quando seu código roda, o usuário já está verificado.

O ponto que me chamou atenção como dev de front é o cuidado com o header. A Vercel remove qualquer valor de x-vercel-oidc-passport-token que venha do cliente e injeta o token verificado depois de validar a sessão. Isso corta um vetor clássico de spoofing de identidade via header forjado.

Lendo o visitante no código

A leitura acontece pelo pacote @vercel/passport:

pnpm add @vercel/passport

O helper getIdentity() lê o contexto da requisição e devolve o visitante autenticado:

import { getIdentity } from '@vercel/passport';

export async function GET() {
  const identity = await getIdentity();
  if (!identity) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }
  return Response.json(identity);
}

O campo subject é um identificador estável do visitante, escopado ao seu time e à aplicação Vercel Connect; externalSubject é o ID dele no provedor. O helper só retorna null quando não há sessão Passport, porque visitantes de navegador sem autenticação são redirecionados ao provedor antes de tocarem seu código.

Um detalhe de DX que agradece: em desenvolvimento local, getIdentity() retorna uma identidade de desenvolvimento configurável. O mesmo caminho de código roda sem provedor real, sem gambiarra de mock.

Autorização por grupo

O token pode carregar claims extras do provedor, como grupos. Você pede o escopo groups, libera a claim na aplicação Vercel Connect e valida:

const identity = await getIdentity();
const groups = identity?.payload.groups ?? [];
if (!groups.includes('engineering')) {
  return Response.json({ error: 'Forbidden' }, { status: 403 });
}

É o suficiente para separar quem vê um painel admin de quem só vê a home, sem manter sua própria tabela de permissões.

Serviços downstream e fora do JS

Se sua aplicação chama outro backend, dá para encaminhar o token como bearer e validá-lo com verifyIdentity() (disponível a partir do @vercel/passport 1.0.0). Ele checa assinatura, claims do Passport e se o token veio do projeto e ambiente esperados. Serviços fora do JavaScript conseguem validar o token como um JWT padrão usando o JWKS publicado, o que abre caminho para backends em Go, Python ou Rust.

Observabilidade e bypass

Cada autenticação bem-sucedida gera um evento passport-access-granted no Activity Log e no Audit Log, com visitante, hostname protegido e projeto. Adeus, mistério de "quem entrou no preview".

Para tráfego automatizado, o Protection Bypass for Automation passou a valer para o Passport: webhooks, cron e runs de CI que já mandam o secret no header x-vercel-protection-bypass continuam funcionando. Atenção a uma pegadinha de arquitetura: como o Passport roda na rede da Vercel antes das suas rotas e proxy functions, o secret precisa estar na requisição original, não adicionado pelo seu middleware. Requisição com bypass não tem visitante logado, então getIdentity() retorna null. Há ainda o Trusted Sources, que faz bypass sem secret compartilhado, aceitando tokens OIDC de curta duração de projetos e serviços autorizados.

O Passport também passou a cobrir ambientes customizados (staging, qa), com o mesmo login que preview e produção já tinham.

Vale a pena?

A limitação honesta: o Passport está disponível apenas no plano Enterprise. Para times menores ou projetos pessoais, a senha compartilhada continua sendo a realidade. Mas para quem já paga Enterprise e vive de previews internos, é uma forma limpa de tirar autenticação e autorização do escopo da aplicação e delegar ao IdP corporativo, com identidade verificada e trilha de auditoria de graça. A documentação traz walkthrough completo do Okta e das claims de token, que recomendo ler antes de configurar em produção.

Fonte: Vercel Changelog