모든 고객을 위한 Cloudflare OAuth

• Cloudflare는 고객이 직접 self-managed OAuth 앱을 만들 수 있게 해, Cloudflare API 접근을 표준 위임 승인 흐름으로 제공할 수 있게 함
• 예전에는 일부 수동 온보딩된 파트너만 타사 OAuth를 쓸 수 있었고, 자체 통합 개발자는 위임형 앱 흐름에 맞지 않는 API 토큰에 의존해야 했음
• 전체 공개를 위해 동의 화면, 철회, 앱 소유권 표시를 개선하고 OAuth 엔진 Hydra를 1.X에서 2.X로 단계적으로 업그레이드함
• 업그레이드 과정에서는 스키마 마이그레이션, 토큰 갱신 오류, 철회 이벤트 유실 위험, 403 증가가 발생했고, 동시 인덱스 생성·철회 재생 큐·데이터 복원으로 대응함
• 업그레이드 후 API P95는 185ms에서 101ms로 45% 감소했고 CPU 사용량도 1.07코어에서 0.67코어로 줄어, 공개 OAuth 운영 기반이 안정화됨

Cloudflare OAuth 공개 범위 확대

• Cloudflare는 플랫폼 API로 자동화, CI/CD, 인프라 통합을 만들 수 있게 해 왔고, 이번에 self-managed OAuth를 모든 고객에게 공개함
• Cloudflare OAuth 자체는 새 기능이 아니며, Wrangler나 PlanetScale 같은 파트너 통합에서 이미 사용돼 왔음
• 다만 기존 타사 OAuth는 소수의 수동 온보딩 통합에만 제공돼, 더 넓은 개발자 생태계에는 열려 있지 않았음
• 자체 통합을 만드는 개발자는 API 토큰에 의존해야 했고, 이 방식은 관리가 어렵고 많은 위임형 애플리케이션 흐름과 잘 맞지 않았음
• self-managed OAuth를 쓰면 개발자는 고객이 직접 범위가 지정된 접근을 승인하는 표준 OAuth 흐름을 제공할 수 있음
  • 주요 사용 사례는 SaaS 통합, 내부 개발자 플랫폼, 에이전트 도구임
  • 사용자는 더 명확한 동의, 쉬운 철회, 애플리케이션 권한에 대한 더 많은 제어를 얻음

전체 공개를 위한 보안 기반 정비

• 초기 OAuth 솔루션은 소수의 관리된 파트너에는 충분했지만, 전체 고객 공개에는 권한 모델, 동의 경험, 남용 완화 방식이 충분히 성숙하지 않았음
• Cloudflare는 올해 초 동의 경험을 개선해 어떤 애플리케이션이 접근을 요청하는지, 어떤 권한을 받을지 더 명확히 표시함
• 대시보드에는 철회 기능을 추가해 개발자가 어떤 애플리케이션이 데이터에 접근할 수 있는지 쉽게 제어할 수 있게 함
• OAuth 피싱 공격을 줄이기 위해 앱 소유권도 더 잘 보이게 만듦
• self-managed OAuth를 모든 고객에게 열려면 사용자 중단을 최소화하면서 데이터 안정성과 보안을 유지하는 OAuth 엔진 업그레이드가 필요했음

Hydra 1.X 업그레이드 준비

• Cloudflare는 오래전부터 오픈소스 OAuth 엔진 Hydra를 Cloudflare OAuth의 내부 엔진으로 사용해 왔음
• 개발자 플랫폼이 성장하고 에이전트 워크플로가 늘면서, 새 기능과 성능 개선을 위한 대규모 업그레이드가 필요해짐
• 한 번에 큰 업그레이드를 하지 않고 최신 1.X 릴리스로 먼저 이동한 뒤, 동작과 성능 변화를 평가하고 2.X 업그레이드로 넘어가는 순차 방식을 선택함
• 1.X 업그레이드만으로도 고객 영향 가능성이 있었음
  • Hydra 데이터베이스가 중요한 테이블에 배타 락을 잡는 방식으로 인덱스를 생성함
  • 중요한 테이블에 컬럼을 추가하고, 다른 컬럼을 새 테이블로 옮김
  • 사용 중이던 Hydra 버전의 SDK가 SELECT *를 수행해 스키마 변경 시 역직렬화 문제가 생길 수 있었음
• 사용자 영향을 막기 위해 SQL 마이그레이션을 CREATE INDEX CONCURRENTLY 같은 방식으로 다시 작성하고, SELECT * 대신 명시적 컬럼을 선택하는 커스텀 Hydra 버전을 만듦

Hydra 2.X 업그레이드 전략

• 2.X 업그레이드는 스키마 변경 규모가 커서 인플레이스 업그레이드가 맞지 않았고, Cloudflare는 blue-green 전략을 선택함
• 단순히 새 버전으로 스위치를 넘기는 방식으로는 충분하지 않았음
  • 업그레이드와 마이그레이션에는 여러 시간이 걸림
  • 그 시간 동안 시스템이 계속 올바르게 동작해야 했음
• 첫 번째 blue-green 옵션은 데이터베이스 쓰기를 막아 새 인가를 차단하는 방식이었음
  • 전환 중 새 쓰기는 손실되지 않음
  • 이미 유효한 자격 증명이 없는 사용자는 기존 OAuth 앱을 쓸 수 없음
  • 업그레이드 중 사용자가 애플리케이션 접근을 철회할 수 없음
• 최종 전략은 데이터베이스 쓰기를 유지하되 일부 쓰기 손실을 감수하고, 손실 위험을 줄이는 방식이었음
  • 새 토큰 쓰기를 줄이기 위해 토큰 만료 시간을 여러 시간으로 늘림
  • 업그레이드 전 토큰을 받은 앱은 새로 갱신하지 않고 계속 사용할 수 있음
• 철회 이벤트 유실은 Cloudflare Queues 기반 큐 시스템으로 막음
  • 철회 이벤트가 발생하면 해당 정보를 큐에 기록함
  • green 버전 데이터베이스로 전환한 뒤 큐를 비워 업그레이드 창 동안의 철회를 재생함
  • 이 처리가 실패하면 사용자가 철회한 애플리케이션의 접근이 의도치 않게 복원될 수 있었음

1.X 업그레이드와 토큰 갱신 문제

• 최신 1.X 릴리스로의 첫 업그레이드는 운영 관점에서 큰 문제 없이 진행됨
• 커스텀 데이터베이스 마이그레이션은 예상보다 빠르게 실행됐고 사용자 영향도 없었음
• 구버전이 새 버전에서 생성된 토큰을 인트로스펙션할 수 없어 하드 컷오버가 필요했음
• 컷오버 후 이전에는 보이지 않던 refresh token 오류가 증가함
  • 새 버전의 더 엄격한 refresh 무효화 동작 때문이었음
  • refresh token이 재사용되면 Hydra가 전체 access token 및 refresh token 체인을 무효화함
  • Wrangler와 MCP 클라이언트는 요청량이 많아, 한 번의 refresh token 재사용으로 전체 세션이 무효화될 수 있었음
• Cloudflare는 OAuth 트래픽을 올바른 목적지로 라우팅하는 Worker에 refresh token coalescing 동작을 추가함
  • Hydra에 도달하기 전 refresh token 요청을 잠시 캐시함
  • 재시도를 감지하면 토큰을 무효화하지 않고 요청을 단축 처리해 응답함
  • Hydra 2.X에는 전체 체인 무효화 없이 일정 시간 refresh token 재시도를 허용하는 설정 가능한 refresh token grace period가 있음

2.X 전환과 복구 과정

• Cloudflare는 사용자 영향이 큰 여러 시간의 중단을 허용할 수 없어 blue-green 업그레이드를 실행함
• 실제 전환에는 단순 데이터베이스 복사와 새 Hydra 배포보다 더 많은 작업이 필요했음
  • 철회 재생 캡처 큐 활성화
  • 데이터베이스 복사 및 새 대상에 복원
  • 새 버전의 제약 조건을 위반하는 기존 데이터 정리
  • Hydra 서비스와 두 개의 핵심 내부 시스템 동시 컷오버
  • 컷오버 후 모니터링과 검증
• 업그레이드 창은 Hydra의 초당 요청 수가 가장 낮은 시간으로 선택해 토큰 쓰기 손실을 최소화함
• 프로덕션 마이그레이션은 일부 타임아웃 튜닝 외에는 새 데이터베이스에서 잘 실행됐고, 순수 실행 시간은 약 3시간이었음
• 트래픽 전환 직후 authorization service의 데이터 정리 작업이 OAuth policy 데이터를 과도하게 삭제하는 현상이 나타남
  • 해당 서비스는 Hydra consent session API에 의존함
  • Hydra 마이그레이션 중 하나가 일부 유효한 OAuth 세션 상태를 손상시켜 유효 세션을 무효로 표시함
  • Hydra와 authorization service 사이의 불일치가 403 증가로 나타남
• Cloudflare는 데이터 복원으로 완화하고, 정적 policy 데이터 의존을 줄이기 위한 OAuth authorization 동작 개선 작업을 시작함
• 그 외 일부 클라이언트별 동작에서 나온 작은 수정도 빠르게 반영됨

업그레이드 후 성능 개선

• Hydra 버전 업그레이드 완료 후 OAuth 트래픽은 안정적으로 유지됐고, 고객을 위한 시스템 성능과 신뢰성이 개선됨
• 새 기반은 staging에서 이미 검증된 신규 OAuth API와 동일한 기반이며, 6월 3일 self-managed OAuth 릴리스를 가능하게 함
• 데이터베이스 마이그레이션 중 관측된 주요 수치:
  • 업데이트된 행: 132.5M
  • 삽입된 행: 114.7M
  • 임시 바이트: 136.97GB
  • 트랜잭션 커밋: 22.2k
• Hydra 평균 성능 지표는 업그레이드 후 전반적으로 개선됨
  • API P95: 185ms → 101ms, 45% 감소
  • RSS 메모리: 888MB → 763MB, 14% 감소
  • Go heap alloc: 449MB → 271MB, 40% 감소
  • Goroutines: 4015 → 3076, 23% 감소
  • CPU: 1.07코어 → 0.67코어, 37% 감소

시작 방법

• 현재 모든 Cloudflare 고객은 자체 OAuth 애플리케이션을 만들고 Cloudflare 위에 통합을 구축할 수 있음
• 시작하려면 문서를 보거나 대시보드의 OAuth apps 페이지에서 첫 OAuth 앱을 만들 수 있음