모두를 위한 OAuth로 Cloudflare 앱 생태계 잠금 해제

본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.

Cloudflare에서는 웹의 20%를 운영하는 데 도움이 되는 서비스를 제공하지만, 이 기능을 단독으로 제공하지는 않습니다. Cloudflare 플랫폼의 개발자들은 다른 회사의 수많은 도구와 서비스를 사용합니다. Cloudflare는 플랫폼을 위해 개발자가 인프라의 다양한 부분을 결합하는 자동화, CI/CD, 통합을 만들 수 있는 풍부한 APIs를 제공합니다. 이번 달 초, Cloudflare API에 대한 위임된 액세스를 위해 고객이 자체 OAuth 클라이언트를 더 쉽게 만들고 관리할 수 있도록 자체 관리형 OAuth를 발표했습니다.

Cloudflare는 OAuth가 처음이 아닙니다. Wrangler를 사용해 보거나 PlanetScale과 같은 파트너의 통합을 사용한 적이 있다면 이미 사용하신 것입니다. 그러나 지금까지 타사 OAuth는 수동으로 온보딩된 소수의 통합을 통해서만 사용할 수 있었으며 개발자가 더 광범위하게 사용할 수 없었습니다. 즉, 자체 통합을 구축하는 개발자는 관리하기가 더 어렵고 많은 위임된 애플리케이션 흐름에 적합하지 않은 API 토큰에 의존해야 했습니다. 

지난 한 해 동안 Cloudflare에서는 점점 더 많은 초기 파트너를 온보딩하면서 Cloudflare OAuth의 동의, 취소, 보안 모델을 개선했습니다. 하지만 Cloudflare의 개발자 플랫폼이 성장하고 에이전트형 도구 덕분에 위임 액세스에 대한 수요가 증가하면서, 모든 고객에게 OAuth를 공개하는 것이 플랫폼 성공의 핵심이라는 것이 분명해졌습니다. 

자체 관리형 OAuth를 통해 개발자는 이제 고객이 직접 범위 지정 액세스 권한을 부여하는 표준 OAuth 흐름을 제공하여 SaaS 통합, 내부 개발자 플랫폼, 에이전트 도구를 더욱 쉽게 구축할 수 있게 됩니다. 응용 프로그램이 수행할 수 있습니다.

신중하게 관리하는 소수의 파트너에게는 초기 OAuth 솔루션으로도 충분했지만, 권한 모델, 동의 경험, 잠재적 남용 벡터를 완화하는 방법이 충분히 성숙하지 않았다는 것을 깨달았습니다. 

올해 초 어떤 애플리케이션이 액세스를 요청하고 있는지, 어떤 권한을 받는지 더욱 명확하게 하기 위해 동의 환경을 업데이트했습니다. 또한 개발자가 어떤 애플리케이션이 자신의 데이터에 액세스할 수 있는지 쉽게 제어할 수 있도록 대시보드에 취소 기능을 추가했고, 앱 소유권을 더 잘 볼 수 있게 하여 OAuth 피싱 공격을 방지했습니다. 

자체 관리 OAuth를 모든 고객에게 공개하려면 기본 OAuth 엔진에 대한 주요 업그레이드도 필요했습니다. 이 과정에서 사용자 방해를 최소화하는 동시에 데이터 안정성과 보안을 보장하기 위한 방대한 계획이 필요했습니다.

몇 년 전, Cloudflare OAuth를 지원하기 위해 오픈 소스 OAuth 엔진인 Hydra를 배포했습니다. 이렇게 사용량이 제한될 때는 배포가 도움이 되었지만, 개발자 플랫폼이 성장하고 에이전트 중심 워크플로우가 일반화되면서 큰 업그레이드를 통해 새로운 기능을 활성화하고 성능을 개선해야 한다는 사실이 분명해졌습니다. 

저희는 업그레이드를 계획할 때 대규모 업그레이드를 한 번 수행하는 것보다 작은 업그레이드를 순차적으로 두 번 수행하기로 결정했습니다.  먼저, 최신 1.X 릴리스로 이동하여 동작이나 성능 변경 사항을 평가한 다음, 2.X 업그레이드를 진행합니다.

Hydra 데이터베이스에는 다음과 같은 광범위한 스키마 마이그레이션이 필요했기 때문에 업그레이드를 계획하는 동안 1.X 업그레이드도 고객에게 여전히 영향을 미칠 수 있다는 것이 분명해졌습니다.

1. 중요한 테이블에 대한 배타적 잠금을 요청하는 방식으로 인덱스를 생성하여 활성 사용자가 중요한 OAuth 작업을 수행할 수 없도록 방지 

2. 중요한 테이블에 열 추가 및 다른 열을 새로운 테이블로 이동

저희가 사용하고 있는 Hydra 버전에도 SDK가 SELECT * 작업을 수행하는 특이한 문제가 있었는데, 이로 인해 스키마 변경 시 역직렬화 문제가 발생했습니다.

사용자에게 미치는 영향을 방지하기 위해 CREATE INDEX CONCURRENTLY 등의 기능을 사용하도록 SQL 마이그레이션을 다시 작성하고 SELECT * 대신 명시적 열을 선택한 Hydra의 사용자 지정 버전을 구축했습니다.

최신 1.X 업그레이드를 계획했으므로, 이제 더 큰 규모의 2.X 업그레이드를 위한 계획을 수립해야 했습니다. 잠재적인 옵션 세 가지를 식별하고 각 옵션의 장단점을 비교했습니다. 전체 업그레이드는 주요 버전 변경으로 인한 스키마 변경의 양 때문에 우리에게 도움이 되지 않았습니다. 우리는 블루-그린 전략이 효과가 있을 것이라고 판단했지만, 새 버전을 사용하기 위해 단순히 스위치를 켜는 것보다 더 많은 작업을 수행해야 했습니다. 업그레이드 및 마이그레이션 프로세스는 몇 시간이 걸렸고, 이 시간 내에 시스템이 계속 올바르게 작동하려면 먼저 시스템이 필요했습니다.

첫 번째 청록색 옵션은 데이터베이스에 대한 쓰기를 비활성화하여 새로운 권한 부여가 발생하지 않도록 하는 것입니다. 이는 전환에서 손실되지 않는다는 것을 의미하지만, 이미 유효한 자격 증명이 없는 한 아무도 기존 OAuth 앱을 사용할 수 없다는 것을 의미했습니다. 이는 또 다른 큰 문제를 야기했습니다. 사용자가 어떤 이유로든 애플리케이션에 대한 액세스를 취소해야 하는 경우 업그레이드가 수행되는 동안에는 취소할 수 없다는 것이었습니다.

이러한 문제를 해결하기 위해 저희는 데이터베이스에 대한 쓰기를 활성화된 상태로 유지하는 방법을 생각해내지만, 친환경 버전으로 전환하면 일부 쓰기 손실을 감수할 수 있습니다. 가장 먼저 해결해야 할 문제는 새로운 토큰의 쓰기 횟수를 최소화하는 것이었습니다. 우리가 토큰의 만료 시간을 몇 시간으로 늘리는 운영 수단이 있었습니다. 이렇게 하면 업그레이드 전에 새 토큰을 받은 앱이 새로 고치지 않고도 토큰을 계속 사용할 수 있습니다.

감소했던 쓰기 문제가 해결되었으므로, 업그레이드 기간 동안 사용자가 수행한 취소를 잃지 않는 방법을 찾아야 했습니다. 이를 위해 철회 이벤트가 발생한 후 해당 철회에 대한 정보와 함께 대기열에 레코드를 작성하는 대기열 시스템(Cloudflare Queues!)을 만들었습니다. 이렇게 하면 데이터베이스를 녹색 버전으로 전환한 상태에서 대기열을 비우고 손실될 수 있는 기간에 발생한 모든 취소 이벤트를 재생할 수 있습니다. 그렇지 않으면 사용자가 취소한 애플리케이션으로 인해 의도치 않게 액세스가 복원될 수 밖에 없습니다.

운영 측면에서 볼 때 마지막 1.X 릴리스로의 첫 번째 업그레이드는 차질 없이 진행되었습니다. Cloudflare의 사용자 지정 데이터베이스 마이그레이션은 예상보다 빠르게 진행되었으며, 사용자에게 영향이 없었습니다. 이전 버전은 최신 버전에서 생성된 토큰을 자체 검사할 수 없었으므로 새 버전으로 하드 전환을 수행해야 했습니다.

전환 이후, 우리는 이전에 볼 수 없었던 갱신 토큰 오류가 증가하는 것을 목격했습니다. 이는 새 버전에서 더 엄격해진 새로 고침 무효화 동작 때문입니다. 리프레시 토큰이 재사용되면 Hydra는 전체 액세스 및 리프레시 토큰 체인을 무효화합니다. 이는 Wrangler와 MCP 클라이언트에 문제가 됩니다. 이 클라이언트들은 모두 요청량이 많으며 리프레시 토큰 하나로 재사용되면 전체 세션이 무효화될 수 있습니다.

Cloudflare는 OAuth 트래픽을 올바른 목적지로 라우팅하는 새로 고침 토큰 병합 동작을 Worker에 추가하여 이 문제를 완화했습니다. 이를 통해 갱신 토큰 요청이 Hydra에 도달하기 전에 잠시 캐시할 수 있으므로 재시도가 감지될 경우 요청을 단락시키고 토큰을 무효화하지 않고 응답할 수 있었습니다. 다행히도 Hydra의 2.X 버전에는 구성 가능한 "갱신 토큰 유예 기간"이 있으므로, 전체 체인을 무효화하지 않고 일정 기간 동안 갱신 토큰을 다시 시도할 수 있도록 하여 이 문제를 해결합니다.

사용자 노출이 높은 작업을 몇 시간 동안 진행하는 것은 허용되지 않았으므로 우리는 블루-그린 업그레이드 전략을 설정했습니다. 높은 수준에서 이는 간단해 보입니다. 프로덕션 데이터베이스의 사본에서 마이그레이션이 실행되고 마이그레이션이 완료되면 새로운 Hydra 버전과 함께 전환됩니다. 실제로는 훨씬 더 많은 역동적인 부분이 있었습니다.

• 철회 재생 캡처 대기열 활성화

• 데이터베이스를 새 대상에 복사하고 복원합니다.

• 대상 데이터 정리 — 기존 데이터가 최신 버전에 도입된 몇 가지 새로운 제약 조건을 위반하여 마이그레이션 성공에 방해가 될 수 있음

• 오류를 방지하기 위해 두 개의 추가 중요 내부 시스템과 함께 Hydra 서비스에 대한 전환을 동시에 수행

• 전환 후 모니터링 및 검증

토큰 쓰기 손실을 최소화하기 위해 Hydra의 초당 요청량이 가장 적을 때 업그레이드 윈도우를 선택했습니다. 시간 초과를 몇 가지 조정한 것 외에는 프로덕션 마이그레이션은 새 데이터베이스에서 잘 실행되었습니다. 프로덕션에서의 순 런타임은 약 3시간이었습니다. 마이그레이션이 완료된 후, 시스템을 새 SDK 버전을 사용하도록 전환하기 위한 두 가지 추가 시스템 구성과 함께 새 버전의 Hydra 서비스를 신중하게 출시했습니다.

트래픽을 차단한 직후, Cloudflare에서는 인증 서비스(Hydra 동의 세션 API에 의존함)에서 데이터 정리 작업이 OAuth 정책 데이터를 지나치게 제거하는 것을 발견했습니다. Cloudflare에서는 조사 결과, Hydra 마이그레이션 중 하나에 문제가 있어 특정 OAuth 세션의 상태가 손상되어, 마이그레이션 과정에서 잘못된 세션으로 표시되는 문제가 발생했다는 사실을 발견했습니다. 유효한 세션이 손상되어 Hydra와 Cloudflare 인증 서비스 간에 불일치가 발생했으며, 이를 통해 403이 증가했습니다. Cloudflare는 이를 완화하기 위해 정적 정책 데이터에 대한 의존을 제거하기 위해 데이터를 복원하고 OAuth 권한 부여 동작을 개선하기 시작했습니다.

데이터 정리 문제 외에도 특정 클라이언트 행동에 따라 몇 가지 추가적인 수정이 있었으며, 우리는 이 문제를 빠르게 해결했습니다. 

Hydra 버전 업그레이드가 완료되어 OAuth 트래픽이 안정적으로 유지되면서 시스템 성능과 고객에 대한 안정성이 개선되었습니다. 또한 새로운 OAuth API가 스테이징에서 이미 검증된 것과 동일한 기반으로 프로덕션을 가동하여, 6월 3일 자체 관리형 OAuth 출시를 위한 길을 열었습니다. 

이와 같은 대규모 업그레이드를 완료한 후에는 그 영향에 대한 몇 가지 광범위한 지표를 살펴보는 것이 항상 보람 있고 긍정적입니다. 데이터베이스 마이그레이션 과정에서 추가 메트릭을 수집했고, 업그레이드가 완료된 후에는 성능이 상당히 개선되는 것을 목격했습니다.

모든 고객에게 OAuth를 공개하는 것은 Cloudflare 앱 생태계를 확장하는 데 중요한 단계입니다. 현재는 모든 Cloudflare 고객이 자체 OAuth 애플리케이션을 생성하고 Cloudflare를 기반으로 통합을 구축할 수 있습니다. 모두를 위한 Cloudflare의 자체 관리 OAuth를 출시하게 되어 매우 기쁩니다. 

시작하려면 문서를 살펴보거나 대시보드의 OAuth 앱 페이지로 바로 이동하여 첫 번째 OAuth 앱을 만드세요.