Vercel의 장기 고정 자격증명 폐기 선언

발행 2026.10.22출처 vercel.com · Malte Ubl

Vercel레퍼런스전문가

15년 전만 해도 TLS는 앱에서 가장 민감한 영역을 보호할 때 쓰는 것이었습니다. 그다음에는 Google, Let's Encrypt, EFF 등이 HTTPS everywhere를 추진하며 모든 요청의 기본값을 암호화로 바꿨습니다. 암호화가 없으면 브라우저와 서버 사이에 있는 누구나 트래픽을 읽고 변조할 수 있습니다.

OAuth, OIDC, DBSC 및 관련 표준은 이미 안전한 인증을 위한 구성 요소를 제공하지만, 표준만으로 안전한 방식이 일반화되지는 않습니다. HTTPS에는 암호화를 쉽게 만들어 주는 도구와, 그것이 당연한 것으로 여겨지게 한 지속적인 추진이 필요했습니다. 머신 간 인증은 아직도 2010년의 HTTPS와 비슷하며, 일부 공급업체와 기업이 앞장서고 있는 반면 장수하는 정적 자격 증명은 여전히 많은 SaaS 공급업체와 인프라 제공업체의 기본값으로 남아 있습니다.

Vercel은 자체 서비스와 Marketplace의 통합을 포함해 웹 전반에서 빠르고 안전한 것을 기본값으로 만들고자 합니다. 우리는 공급업체에 신뢰 정책 양식과 토큰 검증 코드를 제공하는 shadcn/ui 레지스트리인 OIDC UI를 구축했습니다. 또한 Vercel 전반에서 OIDC 지원을 확대하고 있으며 Marketplace 공급업체에 대한 새로운 인증 요구 사항도 도입하고 있습니다.

장수하는 정적 자격 증명은 안전하지 않습니다

장수하는 정적 자격 증명은 API 키나 데이터베이스 비밀번호 같은 비밀 정보로, 애플리케이션이 종종 만료 없이 계속 재사용합니다. 에이전트가 더 유용한 작업을 맡게 되면, 우리는 현재의 작업 범위를 훨씬 넘어서는 권한을 부여할 수 있는 자격 증명을 통해 에이전트에게 시스템, 도구, 데이터에 대한 접근권을 줍니다.

그러한 자격 증명은 코드 저장소나 채팅에 유출될 수 있고, 서비스나 의존성이 침해되면 탈취될 수 있으며, 프롬프트 인젝션으로 인해 에이전트가 이를 드러내게 될 때 노출될 수도 있습니다. 어떤 경로로든, 공격자는 그 자격 증명이 부여하는 권한으로 만료되거나 폐기될 때까지 이를 사용할 수 있습니다. 최근 업계 전반에서 발생한 자격 증명 탈취 및 공급망 사고는, 악성 코드가 운영 환경에서 애플리케이션의 자격 증명을 읽을 수 있을 때 저장 시 암호화만으로는 충분하지 않다는 점을 보여줍니다.

노출된 자격 증명을 순환 교체하려면 이를 사용하는 시스템 전반에서 시간과 조율이 필요하며, 실수는 운영 환경을 중단시킬 수 있습니다. Vercel에서는 이전에 과도한 주의 끝에 여러 번 매우 고통스러운 키 순환 교체 작업에 수천 시간의 엔지니어링 시간을 쏟은 적이 있으며, 우리는 다시는 이런 일을 겪고 싶지 않습니다.

더 나은 해결책은 이미 존재합니다

OIDC를 사용하면 애플리케이션은 장수하는 공급업체 키를 저장하지 않고도 인증할 수 있습니다. 신뢰할 수 있는 발급자가 애플리케이션을 식별하는 서명된 단기 토큰을 제공하고, 이를 받는 서비스는 어떤 접근 권한을 부여할지 결정하기 전에 그 토큰을 검증합니다.

훔친 토큰은 만료되면 더 이상 작동하지 않으므로, 유출이 눈치채지 못한 채 지나가더라도 그 복사본이 사용될 수 있는 시간이 제한됩니다. 애플리케이션은 프로그래밍 방식으로 새로운 자격 증명을 얻을 수 있으므로, 이를 사용하는 시스템 전체에 영구적인 공급업체 키를 배포하고 수동으로 순환 교체할 필요가 없어집니다.

우리는 Vercel 전반에서 OIDC를 우선순위로 두고 있으며, 그 결과 애플리케이션이 이들 서비스에 대해 장수하는 키를 저장하지 않고도 Blob, AI Gateway, Sandbox에 접근할 수 있게 하고 있습니다. 우리의 OIDC federation은 2024년부터 일반 제공되고 있으며, Vercel에서 실행되는 애플리케이션이 구성된 프로젝트 및 환경 신뢰 정책에 따라 Vercel이 발급한 ID 토큰을 임시 AWS, Google Cloud, Azure 자격 증명과 교환할 수 있게 합니다. 하지만 개발자가 장수하는 키 관리를 멈추려면, 그 지원이 애플리케이션이 의존하는 모든 서비스로 확장되어야 합니다.

웹의 나머지는 따라오지 않았습니다

우리는 1,000개가 넘는 SaaS 공급업체를 조사했고, 그중 안전한 인증 방식을 지원한 곳은 8.4%뿐이라는 사실을 확인했습니다.

하지만 공급업체가 안전한 인증을 지원하게 만드는 것만이 문제의 전부는 아닙니다. 서비스가 안전한 방식을 제공하더라도, 개발자들은 종종 사용이 더 단순할 수 있다는 이유로 정적 키를 선택합니다. 우리는 더 넓은 채택을 가로막는 주된 장벽을 세 가지로 봅니다.

안전한 인증을 정적 키보다 더 복잡하게 만드는 도구와 설정.
요청 경로에서 토큰을 가져오거나 교환할 때 발생하는 추가 지연.
공급업체가 안전한 인증을 제공하고 우선순위를 두도록 만드는 약한 유인.

우리의 목표는 Vercel에서 보안 인증을 기본값으로 만드는 동시에, Marketplace를 활용해 더 많은 벤더가 이를 지원하도록 유도하는 것입니다.

더 안전한 웹을 위한 우리의 약속

우리는 우리가 운영하는 서비스, 개발자가 사용하는 도구, 그리고 파트너와 함께 구축하는 통합 전반에 걸쳐 이 변화를 실용적으로 만드는 책임이 있습니다.

보안 인증을 더 쉽게 사용하게 만들기

보안 토큰을 사용하는 것이 키를 붙여 넣는 것보다 쉬워야 합니다. 그렇지 않으면 개발자들은 계속 키를 붙여 넣게 될 것입니다. Vercel에서는 코드가 함수 호출로 OIDC 토큰을 가져오며, custom audience는 이를 받도록 의도된 서비스를 지정합니다.

Vercel Connect를 사용하면 애플리케이션과 에이전트가 배포 신원을 사용해 런타임에 공급자 토큰을 요청할 수 있으며, 환경 변수에 장기 사용 공급자 비밀값을 저장할 필요가 없습니다. 커넥터가 구성되고 프로젝트에 연결되며 사용자의 계정이 연결되면, 코드는 해당 사용자를 위해 공급자가 지원하는 범위의 토큰을 요청할 수 있습니다.

app/api/agent/route.ts

typescript

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

3
const token = await getToken('oauth/linear', {
4
  subject: { type: 'user', id: 'user_123' },
5
  scopes: ['read'],
6
});

Vercel Connect를 통해 사용자에게 Linear 접근 권한을 요청하기

또한 배포 워크플로에서 장기 사용 Vercel 토큰이 필요하지 않도록, Vercel API와 CLI 전반에 OIDC 지원을 확장하고 있습니다.

API 제공자를 위한 OIDC UI

OIDC UI는 신뢰 정책 구성기와 서버 측 토큰 검증기를 갖춘 shadcn/ui 컴포넌트 레지스트리입니다. 여기에는 Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure, 그리고 커스텀 OIDC 발급자용 제공자 폼이 포함되어 있습니다. 제공자는 고객이 특정 Vercel 프로젝트의 프로덕션 환경에 대한 신뢰를 구성하도록 한 다음, 설정 인터페이스와 검증 코드를 처음부터 만들지 않고도 해당 정책에 대해 들어오는 토큰을 검증할 수 있습니다.

왼쪽에 ID 제공자, 폼 라이브러리, 검증기 옵션이 있고 오른쪽에 Vercel 신뢰 정책 폼 미리보기가 있는 OIDC UI 빌더.

서비스를 위한 신뢰 정책 폼과 토큰 검증 코드를 생성합니다.

보안 인증의 성능 비용 줄이기

환경 변수에 있는 정적 키는 함수가 실행될 때 이미 사용할 수 있으므로, 이를 읽는 데 네트워크 요청이 필요하지 않습니다. 토큰을 가져오거나 그것을 공급자 자격 증명으로 교환하는 과정은 네트워크 지연을 추가할 수 있으므로, 이러한 호출을 줄이는 것은 보안 인증을 실용적으로 만드는 데 중요한 부분입니다.

Vercel Functions는 요청 헤더에서 플랫폼이 발급한 토큰을 받으며, SDK는 추가로 가져오지 않고 이를 읽습니다. 플랫폼은 만료되지 않은 토큰을 재사용하며, Vercel Connect는 프로세스 내에서 공급자 토큰을 캐시하고 만료 시점이 가까워지면 갱신합니다. custom-audience와 공급자 교환에는 네트워크 호출이 필요합니다.

예를 들어, 애플리케이션은 데이터베이스 키 대신 임시 자격 증명으로 Cosmos DB에 접근하기 위해 Azure SDK를 사용할 수 있습니다. Azure가 Vercel 프로젝트와 해당 기본 토큰 대상 그룹을 신뢰하도록 구성되어 있으면, 콜백은 ClientAssertionCredential에 Vercel OIDC 토큰을 전달하고, ClientAssertionCredential은 이를 CosmosClient가 사용하는 Azure 액세스 토큰으로 교환합니다.

lib/cosmos.ts

typescript

123456789101112131415161718192021222324252627281
import { getVercelOidcToken } from '@vercel/oidc';
2
import { ClientAssertionCredential } from '@azure/identity';
3
import { CosmosClient } from '@azure/cosmos';
4

5
const credentialsProvider = new ClientAssertionCredential(
6
  process.env.AZURE_TENANT_ID!,
7
  process.env.AZURE_CLIENT_ID!,
8
  () => getVercelOidcToken(),
9
);
10

11
const cosmosClient = new CosmosClient({
12
  endpoint: process.env.COSMOS_DB_ENDPOINT!,
13
  aadCredentials: credentialsProvider,
14
});

Vercel OIDC 토큰을 Azure Cosmos DB 접근용으로 교환하기

제공자가 안전한 인증을 지원하도록 유도하기

Vercel Marketplace는 타사 데이터베이스, 콘텐츠 관리 시스템, 관측 도구 등 다양한 서비스에 대한 접근을 제공합니다. 우리의 목표는 이 모든 공급업체가 OIDC 토큰을 직접 받든, 이를 임시 자격 증명으로 교환하든, 수명이 짧은 ID 기반 인증을 지원하도록 하는 것입니다. 개발자가 서비스를 연결할 때 해당 인증이 자동으로 구성되도록 통합 기능을 개선하고 있으며, 따라서 별도의 설정 단계가 필요하지 않게 만들고 있습니다.

HTTPS 전환이 편의성만으로 성공한 것은 아니었습니다. Chrome은 일반 HTTP에 “Not secure” 라벨을 붙였고, 이어서 마감 기한을 설정했습니다. 이제 우리가 우리의 기준을 정합니다. 2026년 11월 30일까지 Vercel에서 서비스에 대한 OIDC 인증을 지원하지 않고, 인증에 장기 비밀 정보를 사용하는 공급업체는 해당 목록에 비슷한 “Not secure” 메시지가 표시됩니다. 2027년 1월까지 안전한 인증을 제공하지 않는 공급업체는 목록에서 제외됩니다. 우리는 Vercel API와 자체 네이티브 통합에도 같은 기준을 적용하고 있습니다.

정적에서 동적으로

15년 전에는 모든 요청을 암호화하는 것이 과한 일처럼 느껴졌습니다. 오늘날 자물쇠 아이콘은 너무나 당연해서, 없을 때만 눈에 띕니다. 서비스 간의 안전한 인증도 마찬가지로 일상적인 것이 되어야 하며, 개발자는 또 다른 장기 비밀 정보를 저장하지 않고도 필요한 시스템을 연결할 수 있어야 합니다. 정적에서 동적으로 전환하는 것은 언제나 Vercel의 사명이었습니다. 처음에는 페이지에서 시작했고, 이제는 자격 증명입니다.

추가 자료

OIDC 연합은 배포가 어떻게 수명이 짧은 ID 토큰을 얻는지 다루며, AWS, GCP, Azure 및 자체 API에 대한 가이드를 제공합니다.
사용자 지정 OIDC 토큰 대상 그룹은 각 토큰을 이를 받아야 하는 하나의 서비스에만 범위를 지정합니다.
Vercel Connect는 런타임에 수명이 짧고 범위가 지정된 공급자 토큰을 요청하므로, 코드와 에이전트가 자격 증명을 저장하지 않습니다.
Vercel Connect 가이드는 Slack 봇부터 GitHub 에이전트까지, 이러한 방식으로 에이전트를 구축하는 방법을 안내합니다.