수명이 긴 정적 자격 증명과의 작별

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

OAuth, OIDC, DBSC 같은 표준은 이미 안전한 인증을 위한 기반을 갖추고 있습니다. 하지만 표준이 있다고 해서 안전한 방식이 저절로 일반화되지는 않습니다. HTTPS가 자리 잡으려면 암호화를 쉽게 적용할 수 있는 도구와, 이를 당연한 것으로 만드는 꾸준한 압박이 필요했습니다. 머신 간 인증은 아직 2010년의 HTTPS와 비슷한 단계입니다. 일부 공급업체와 기업이 앞서가고 있지만, 많은 SaaS 업체와 인프라 제공업체에서는 여전히 수명이 긴 정적 자격 증명이 기본값입니다.

Vercel은 자사 서비스와 Marketplace 통합을 포함해 웹 전반에서 빠르면서도 안전한 환경이 기본이 되기를 바랍니다. 이를 위해 OIDC UI를 만들었습니다. OIDC UI는 제공업체에 신뢰 정책(trust policy) 폼과 토큰 검증 코드를 제공하는 shadcn/ui 레지스트리입니다. 또한 Vercel 전반으로 OIDC 지원을 넓히고, Marketplace 제공업체에 적용할 새로운 인증 요건도 마련하고 있습니다.

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

수명이 긴 정적 자격 증명이란 API 키나 데이터베이스 비밀번호처럼 애플리케이션이 만료 기한 없이 계속 재사용하는 시크릿을 말합니다. 에이전트가 더 많은 일을 맡게 되면서, 우리는 에이전트에게 시스템, 도구, 데이터에 대한 접근 권한을 자격 증명으로 부여합니다. 이 자격 증명은 실제 작업에 필요한 범위를 훨씬 넘어서는 권한을 줄 수 있습니다.

이런 자격 증명은 코드 저장소나 채팅에 유출되기도 하고, 서비스나 의존성이 침해될 때 탈취되기도 하며, 프롬프트 인젝션에 속은 에이전트가 직접 노출하기도 합니다. 경로가 무엇이든, 공격자는 자격 증명이 만료되거나 폐기될 때까지 그 권한을 그대로 사용할 수 있습니다. 최근 업계에서 잇따른 자격 증명 탈취 및 공급망 사고는, 악성 코드가 프로덕션에서 애플리케이션의 자격 증명을 읽을 수 있다면 저장 시 암호화(encryption at rest)만으로는 부족하다는 점을 보여 줍니다.

노출된 자격 증명을 교체하려면 시간이 걸리고, 해당 자격 증명을 쓰는 여러 시스템 간에 조율도 필요합니다. 실수가 생기면 프로덕션에 장애가 날 수도 있습니다. Vercel도 과거에 만약의 사태에 대비해 여러 차례 매우 고통스러운 키 교체 작업을 하느라 수천 시간의 엔지니어링 리소스를 쏟았고, 다시는 이런 일을 겪고 싶지 않습니다.

이미 더 나은 해법이 있습니다

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

탈취된 토큰은 만료되면 쓸 수 없게 됩니다. 유출을 알아차리지 못하더라도 그 사본을 사용할 수 있는 시간이 제한되는 셈입니다. 애플리케이션이 새 자격 증명을 프로그래밍 방식으로 직접 받아 올 수 있으므로, 지속적으로 쓰는 제공업체 키를 여러 시스템에 배포하고 수동으로 교체할 필요도 없어집니다.

Vercel은 애플리케이션이 수명이 긴 키를 저장하지 않고도 Blob, AI Gateway, Sandbox에 접근할 수 있도록 Vercel 전반에서 OIDC를 우선적으로 지원해 왔습니다. OIDC 페더레이션은 2024년부터 정식 출시(GA)되어 있으며, Vercel에서 실행되는 애플리케이션은 설정된 프로젝트 및 환경별 신뢰 정책에 따라 Vercel이 발급한 ID 토큰을 AWS, Google Cloud, Azure의 임시 자격 증명으로 교환할 수 있습니다. 하지만 개발자가 수명이 긴 키를 더 이상 관리하지 않으려면, 애플리케이션이 의존하는 모든 서비스로 이 지원이 확대되어야 합니다.

웹의 나머지 영역은 아직 따라오지 못했습니다

1,000곳이 넘는 SaaS 공급업체를 조사한 결과, 안전한 인증 방식을 지원하는 곳은 8.4%에 불과했습니다.

그렇다고 공급업체의 지원만 늘린다고 문제가 해결되지는 않습니다. 서비스가 안전한 방식을 제공하더라도, 개발자는 쓰기 더 간편하다는 이유로 정적 키를 고르는 경우가 많습니다. 더 널리 도입되지 못하는 데에는 크게 세 가지 걸림돌이 있습니다.

• 도구와 설정 과정 때문에 안전한 인증이 정적 키를 쓰는 것보다 복잡합니다.

• 요청 경로에서 토큰을 가져오거나 교환하느라 지연 시간이 늘어납니다.

• 공급업체가 안전한 인증을 제공하고 우선순위를 둘 만한 유인이 약합니다.

Vercel의 목표는 Vercel에서 안전한 인증을 기본값으로 만드는 것입니다. 아울러 Marketplace를 활용해 더 많은 공급업체가 안전한 인증을 지원하도록 이끌려고 합니다.

더 안전한 웹을 위한 Vercel의 약속

Vercel은 우리가 운영하는 서비스, 개발자가 사용하는 도구, 파트너와 함께 만드는 통합 전반에서 이 변화가 현실적으로 자리 잡도록 만들 책임이 있다고 생각합니다.

안전한 인증을 더 쉽게 쓸 수 있도록

안전한 토큰을 쓰는 일이 키를 붙여 넣는 일보다 쉬워야 합니다. 그렇지 않으면 개발자는 계속 키를 붙여 넣을 것입니다. Vercel에서는 코드에서 함수를 호출해 OIDC 토큰을 가져올 수 있고, 커스텀 audience로 토큰을 받을 서비스를 지정할 수 있습니다.

Vercel Connect를 쓰면 애플리케이션과 에이전트가 배포 ID(deployment identity)로 런타임에 제공업체 토큰을 요청하므로, 수명이 긴 제공업체 시크릿을 환경 변수에 저장할 필요가 없습니다. 커넥터를 설정해 프로젝트에 연결하고 사용자 계정까지 연동하고 나면, 코드에서 제공업체가 지원하는 스코프로 해당 사용자용 토큰을 요청할 수 있습니다.

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

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

또한 Vercel API와 CLI에도 OIDC 지원을 확대하고 있습니다. 배포 워크플로에서 수명이 긴 Vercel 토큰을 쓸 필요가 없도록 하기 위해서입니다.

API 제공업체를 위한 OIDC UI

OIDC UI는 신뢰 정책 설정 도구와 서버 측 토큰 검증기를 갖춘 shadcn/ui 컴포넌트 레지스트리입니다. Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure, 그리고 커스텀 OIDC 발급자용 폼이 들어 있습니다. 제공업체는 고객이 특정 Vercel 프로젝트의 프로덕션 환경을 신뢰하도록 설정하게 하고, 들어오는 토큰을 그 정책에 따라 검증할 수 있습니다. 설정 화면과 검증 코드를 처음부터 만들 필요가 없습니다.

안전한 인증의 성능 부담 줄이기

환경 변수에 담긴 정적 키는 함수가 실행될 때 이미 준비되어 있으므로, 읽는 데 네트워크 요청이 필요 없습니다. 반면 토큰을 가져오거나 제공업체 자격 증명으로 교환하는 과정에서는 네트워크 지연이 생길 수 있습니다. 그래서 이런 호출을 줄이는 것도 안전한 인증을 실용적으로 만드는 일의 일부입니다.

Vercel Functions는 요청 헤더로 플랫폼이 발급한 토큰을 받고, SDK는 이 토큰을 읽을 뿐 별도로 가져오지 않습니다. 플랫폼은 만료되지 않은 토큰을 재사용하며, Vercel Connect는 제공업체 토큰을 프로세스 내에 캐시해 두었다가 만료가 가까워지면 갱신합니다. 다만 커스텀 audience나 제공업체와의 교환에는 네트워크 호출이 필요합니다.

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

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

const credentialsProvider = new ClientAssertionCredential(
  process.env.AZURE_TENANT_ID!,
  process.env.AZURE_CLIENT_ID!,
  () => getVercelOidcToken(),
);

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

공급업체가 안전한 인증을 지원할 동기 부여하기

Vercel Marketplace에서는 서드파티 데이터베이스, 콘텐츠 관리 시스템(CMS), 옵저버빌리티 도구 등을 이용할 수 있습니다. Vercel의 목표는 이 모든 공급업체가 OIDC 토큰을 직접 받든 임시 자격 증명으로 교환하든, 수명이 짧은 ID 기반 인증을 지원하게 하는 것입니다. 개발자가 서비스를 연결할 때 통합이 이 인증을 자동으로 설정해, 별도의 설정 단계가 필요 없도록 만들고 있습니다.

HTTPS가 보편화된 것은 사용 편의성만으로 이룬 결과가 아닙니다. Chrome은 일반 HTTP에 "안전하지 않음" 표시를 붙였고, 이어서 기한까지 못 박았습니다. 이제 Vercel도 기한을 제시합니다. 2026년 11월 30일까지 Vercel에서 자사 서비스로 들어오는 OIDC 인증을 지원하지 않고 수명이 긴 시크릿으로 인증하는 공급업체는, 목록 페이지에 비슷한 "안전하지 않음" 문구가 표시됩니다. 2027년 1월까지도 안전한 인증을 제공하지 않는 공급업체는 목록에서 제외됩니다. Vercel API와 Vercel의 자체 네이티브 통합에도 똑같은 기준을 적용합니다.

정적에서 동적으로

15년 전에는 모든 요청을 암호화하는 일이 과하게 느껴졌습니다. 지금은 자물쇠 아이콘이 너무나 당연해서, 없을 때에야 비로소 눈에 띕니다. 서비스 간 안전한 인증도 이처럼 일상적인 일이 되어야 합니다. 그래야 개발자가 수명이 긴 시크릿을 또 저장하지 않고도 필요한 시스템을 연결할 수 있습니다. 정적인 것에서 동적인 것으로 나아가는 일은 Vercel이 처음부터 추구해 온 사명입니다. 페이지에서 시작한 그 여정이 이제 자격 증명으로 이어집니다.

추가 자료

• OIDC 페더레이션 문서에서는 배포 환경이 수명이 짧은 ID 토큰을 받는 방법을 다루며, AWS, GCP, Azure, 자체 API용 가이드도 제공합니다.

• 커스텀 OIDC 토큰 audience를 쓰면 각 토큰의 사용 범위를 해당 토큰을 받을 서비스 하나로 한정할 수 있습니다.

• Vercel Connect는 런타임에 수명이 짧고 범위가 제한된 제공업체 토큰을 요청하므로, 코드와 에이전트가 자격 증명을 저장할 필요가 없습니다.

• Vercel Connect 가이드에서는 Slack 봇부터 GitHub 에이전트까지, 이 방식으로 에이전트를 만드는 과정을 단계별로 안내합니다.

기여자