15년 전만 해도 TLS는 앱의 가장 민감한 영역을 보호하는 데 사용되는 기술이었습니다. 이후 Google, Let's Encrypt, EFF 등이 HTTPS를 모든 곳에 적용하도록 주도하면서 암호화가 모든 요청의 기본값이 되었습니다. 이것이 없었다면 브라우저와 서버 사이에 있는 누구나 트래픽을 읽고 변조할 수 있습니다.
OAuth, OIDC, DBSC 및 관련 표준은 이미 안전한 인증을 위한 빌딩 블록을 제공하지만, 표준만으로는 보안 방식을 일반적인 규범으로 만들지 못합니다. HTTPS는 암호화를 쉽게 만들어주고 그것이 기대되는 것이 되도록 지속적으로 추진하는 도구가 필요했습니다. 기계 대 기계(Machine-to-machine) 인증은 2010년에도 여전히 HTTPS와 유사한 모습을 보이며, 일부 공급업체와 기업들이 앞장서고 있지만, 많은 SaaS 공급업체와 인프라 제공업체에게는 장기 지속형 정적 자격 증명(long-lived static credentials)이 기본값으로 남아 있습니다.
Vercel은 자체 서비스 및 Marketplace의 통합을 포함하여 웹 전반에 걸쳐 빠르고 안전한 것을 기본값으로 만들고자 합니다. 저희는 공급자들에게 신뢰 정책 양식과 토큰 검증 코드를 제공하는 shadcn/ui 레지스트리인 OIDC UI를 구축했습니다. 또한 Vercel 전반에 걸쳐 OIDC 지원을 확장하고 Marketplace 공급자들을 위한 새로운 인증 요구 사항을 설정하고 있습니다.
장기 지속형 정적 자격 증명은 API 키나 데이터베이스 비밀번호와 같이 애플리케이션이 재사용하며 만료일이 없는 경우가 많은 비밀 정보입니다. 에이전트(agent)가 더 유용한 작업을 맡게 되면서, 우리는 그들에게 현재 작업 범위를 훨씬 넘어선 권한을 부여할 수 있는 자격 증명을 통해 시스템, 도구 및 데이터에 접근하도록 합니다.
하지만 이러한 자격 증명은 코드 저장소나 채팅에 유출되거나, 서비스 또는 종속성이 손상되었을 때 도난당하거나, 프롬프트 주입(prompt injection)이 에이전트가 이를 노출하게 만들 때 노출될 수 있습니다. 그러나 어떤 방식으로든 발생하면, 공격자는 해당 자격 증명이 만료되거나 취소될 때까지 부여된 권한으로 사용할 수 있습니다. 업계 전반에 걸쳐 최근 발생한 자격 증명 도난 및 공급망 사고들은 악성 코드가 프로덕션 환경에서 애플리케이션의 자격 증명을 읽을 수 있을 때, 단순히 저장된 암호화(encryption at rest)만으로는 충분하지 않다는 것을 보여줍니다.
노출된 자격 증명(credentials)을 주기적으로 교체하는 작업은 해당 시스템 전반에 걸쳐 시간과 조율이 필요하며, 실수할 경우 운영 환경에 차질을 줄 수 있습니다. Vercel에서는 예방적 차원에서 여러 번의 매우 고통스러운 키 로테이션(key rotations)에 엔지니어링 시간을 수천 시간에 달해 지출한 적이 있으며, 다시는 이런 일을 겪고 싶지 않습니다.
[Missing Name],를 사용하면 애플리케이션이 장기 지속형 제공자 키(long-lived provider key)를 저장하지 않고도 인증할 수 있습니다. 신뢰할 수 있는 발급자(issuer)가 애플리케이션을 식별하는 서명된 단기 토큰(short-lived token)을 제공하고, 수신 서비스는 어떤 접근 권한을 부여할지 결정하기 전에 해당 토큰을 검증합니다.OIDC
도난당한 토큰은 만료되면 작동을 멈추므로, 유출이 감지되지 않더라도 해당 사본을 사용할 수 있는 기간이 제한됩니다. 애플리케이션은 새로운 자격 증명(credentials)을 프로그래밍 방식으로 얻을 수 있어, 이를 사용하는 시스템 전반에 걸쳐 지속적인 제공자 키를 배포하고 수동으로 교체할 필요가 없습니다.
저희는 애플리케이션이 해당 서비스에 대한 장기 지속형 키를 저장하지 않고도 접근할 수 있도록 Vercel 전반에서 OIDC를 우선순위에 두고 지원해 왔습니다. [Missing Name]은 2024년부터 일반적으로 사용 가능(generally available)했으며, Vercel에서 실행되는 애플리케이션이 구성된 [Missing Name] 하에 Vercel 발급의 ID 토큰을 임시 AWS, Google Cloud 및 Azure 자격 증명으로 교환할 수 있게 했습니다. 하지만 개발자들이 장기 지속형 키 관리를 중단하려면, 이 지원이 애플리케이션이 의존하는 모든 서비스로 확장되어야 합니다.BlobAI GatewaySandboxOIDC federationproject and environment trust policies
저희는 1,000개 이상의 SaaS 공급업체를 대상으로 설문조사를 실시했으며, 단지 8.4%만이 안전한 인증 방법을 지원하는 것을 발견했습니다.
하지만 공급업체들이 안전한 인증을 지원하도록 만드는 것 자체가 문제의 일부일 뿐입니다. 서비스가 안전한 방법을 제공하더라도, 개발자들은 사용하기 더 간단하다는 이유로 여전히 정적 키(static key)를 선택하는 경우가 많습니다. 우리는 광범위한 채택에 있어 세 가지 주요 장벽을 발견했습니다.
우리의 목표는 Vercel에서 안전한 인증을 기본값으로 만드는 동시에, Marketplace를 활용하여 더 많은 공급업체가 이를 지원하도록 독려하는 것입니다.
우리는 우리가 운영하는 서비스 전반, 개발자가 사용하는 도구, 그리고 파트너와 구축하는 통합(integration)에 걸쳐 이 변화를 실용적으로 만들 책임이 있습니다.
안전한 토큰을 사용하는 것이 키를 붙여넣는 것보다 쉬워야 합니다. 그렇지 않으면 개발자들은 계속해서 키를 붙여넣을 것입니다. Vercel에서는 코드가 함수 호출과 함께 OIDC 토큰을 검색하며, 커스텀 오디언스(custom audience)가 이를 수신할 의도된 서비스를 지정합니다.
Vercel Connect를 사용하면 애플리케이션과 에이전트가 런타임(runtime)에 배포 ID(deployment identity)를 사용하여 공급자 토큰을 요청하며, 환경 변수에 장기 지속되는 공급자 비밀(long-lived provider secrets)을 저장할 필요가 없습니다. 커넥터가 구성되어 프로젝트에 연결되고 사용자 계정이 연결되면, 코드는 해당 사용자를 위한 토큰을 요청할 수 있으며 이 토큰은 공급자가 지원하는 스코프(scope)를 가집니다.
또한 우리는 배포 워크플로우에서 장기 지속되는 Vercel 토큰의 필요성을 제거하기 위해 OIDC 지원을 Vercel API와 CLI 전반으로 확장하고 있습니다.
OIDC UI는 신뢰 정책 구성기(trust-policy configurator)와 서버 측 토큰 검증기(server-side token verifier)를 갖춘 shadcn/ui 컴포넌트 레지스트리입니다. 여기에는 Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure 및 커스텀 OIDC 발급자(issuer)에 대한 공급자 양식(provider forms)이 포함되어 있습니다. 공급자는 고객이 특정 Vercel 프로젝트의 프로덕션 환경에 대한 신뢰를 구성하도록 허용할 수 있으며, 이를 위해 설정 인터페이스와 검증 코드를 처음부터 구축할 필요 없이 들어오는 토큰을 해당 정책과 비교하여 검증할 수 있습니다.
환경 변수에 있는 정적 키는 함수가 실행될 때 이미 사용 가능하므로, 이를 읽는 데 네트워크 요청이 필요하지 않습니다. 토큰을 가져오거나 제공업체 자격 증명(provider credentials)으로 교환하는 것은 네트워크 지연 시간(network latency)을 추가할 수 있으므로, 이러한 호출을 줄이는 것이 안전한 인증을 실용적으로 만드는 부분입니다.
Vercel Functions는 요청 헤더에서 플랫폼이 발행한 토큰을 받으며, 별도의 가져오기 과정 없이 사용됩니다. 플랫폼은 만료되지 않은 토큰을 재사용하는 반면, 사용자 지정 오디언스(Custom-audience) 및 제공업체 교환에는 네트워크 호출이 필요합니다.the SDK readsVercel Connect는 프로세스에 제공업체 토큰을 캐시하고 만료가 임박했을 때 새로 고칩니다
예를 들어, 애플리케이션은 데이터베이스 키 대신 임시 자격 증명(temporary credentials)을 사용하여 Azure SDK로 Cosmos DB에 접근할 수 있습니다. Vercel 프로젝트와 기본 토큰 오디언스(default token audience)를 신뢰하도록 구성된 경우, 콜백은 Vercel OIDC 토큰을 AzureClientAssertionCredential``CosmosClient에 제공하고, 이 토큰을 해당 클라이언트가 사용하는 Azure 액세스 토큰으로 교환합니다.
이는 타사 데이터베이스, 콘텐츠 관리 시스템(CMS), 관측 가능성 도구(observability tools) 등에 대한 액세스를 제공합니다. 우리의 목표는 이 모든 공급업체들이 OIDC 토큰을 직접 수락하든 임시 자격 증명으로 교환하든 관계없이, 짧은 수명의(short-lived), ID 기반 인증(identity-based authentication)을 지원하는 것입니다. 저희는 개발자가 서비스를 연결할 때 통합(integrations)이 해당 인증을 자동으로 구성하도록 작업하고 있으며, 따라서 별도의 설정 단계가 필요하지 않게 만들고 있습니다.Vercel Marketplace
HTTPS가 모든 곳에서 통용되는 것은 단순히 사용 편의성 때문만은 아니었습니다. Chrome은 일반 HTTP에 “안전하지 않음(Not secure)” 라벨을 붙였고, 이후 마감 기한을 설정했습니다. 이제 저희가 그 시기를 정하고 있습니다. 2026년 11월 30일까지 Vercel에서 서비스로 OIDC 인증(OIDC auth)을 지원하지 않고 장기 지속형 비밀 키(long-lived secrets)를 사용하여 인증하는 공급업체들은 자신들의 목록에 유사한 “안전하지 않음” 메시지를 받게 될 것입니다. 2027년 1월까지는 보안 인증을 제공하지 않는 공급업체들이 목록에서 제외될 것입니다. 저희는 Vercel API와 자체 네이티브 통합에도 동일한 기준을 적용하고 있습니다.
15년 전만 해도 모든 요청을 암호화하는 것은 과도한 조치처럼 느껴졌습니다. 오늘날에는 자물쇠 아이콘이 너무나 당연해서, 오히려 그것이 없을 때에야 그 부재를 깨닫게 됩니다. 서비스 간의 보안 인증 역시 이만큼 일상적인 것이 되어야 하며, 개발자들이 또 다른 장기 지속형 비밀 키를 저장할 필요 없이 필요한 시스템들을 연결할 수 있어야 합니다. 정적(static)에서 동적(dynamic)으로 전환하는 것은 항상 Vercel의 목표였습니다. 처음에는 페이지에 관한 것이었고, 이제는 자격 증명(credentials)에 관한 것입니다.
더 읽기
장기 지속형 정적 자격 증명은 안전하지 않다
더 나은 해결책이 이미 존재한다
웹의 나머지는 따라오지 않았다
더욱 안전한 웹을 위한 우리의 약속
정적에서 동적으로
추가 자료
-
장기 지속형 키를 사용하는 것보다 보안 인증이 더 복잡하게 만드는 도구 및 설정.
-
요청 경로에서 토큰을 가져오거나 교환하는 과정에서 지연 시간(latency) 추가됨.
-
공급업체가 보안 인증을 제공하고 우선순위를 높일 동기가 약함.
-
배포 환경이 어떻게 단기 식별 토큰을 얻는지 다루며, AWS, GCP, Azure 및 자체 API에 대한 가이드도 제공합니다.[OIDC federation]
-
각 토큰의 범위를 해당 토큰을 받아야 하는 단일 서비스로 제한합니다.[Custom OIDC token audiences]
-
런타임에 단기적이고 범위가 지정된 프로바이더 토큰을 요청하여, 코드와 에이전트가 자격 증명을 절대 저장하지 않도록 합니다.[Vercel Connect]
-
Slack 봇부터 GitHub 에이전트에 이르기까지 이러한 방식으로 에이전트를 구축하는 과정을 안내합니다.[Vercel Connect guides]
안전한 인증 사용 간소화
API 제공자를 위한 OIDC UI
안전한 인증 구현에 따른 성능 부하(cost) 절감
제공자가 안전한 인증을 지원하도록 인센티브 부여