# 모든 고객을 위한 Cloudflare OAuth > Clean Markdown view of GeekNews topic #30845. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30845](https://news.hada.io/topic?id=30845) - GeekNews Markdown: [https://news.hada.io/topic/30845.md](https://news.hada.io/topic/30845.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-26T10:11:49+09:00 - Updated: 2026-06-26T10:11:49+09:00 - Original source: [blog.cloudflare.com](https://blog.cloudflare.com/oauth-for-all/) - Points: 5 - Comments: 1 ## Topic Body - 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는 올해 초 [동의 경험](https://blog.cloudflare.com/improved-developer-security/#improving-the-oauth-consent-experience)을 개선해 어떤 애플리케이션이 접근을 요청하는지, 어떤 권한을 받을지 더 명확히 표시함 - 대시보드에는 **철회 기능**을 추가해 개발자가 어떤 애플리케이션이 데이터에 접근할 수 있는지 쉽게 제어할 수 있게 함 - OAuth 피싱 공격을 줄이기 위해 **앱 소유권**도 더 잘 보이게 만듦 - self-managed OAuth를 모든 고객에게 열려면 사용자 중단을 최소화하면서 데이터 안정성과 보안을 유지하는 OAuth 엔진 업그레이드가 필요했음 ### Hydra 1.X 업그레이드 준비 - Cloudflare는 오래전부터 오픈소스 OAuth 엔진 [Hydra](https://github.com/ory/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](https://developers.cloudflare.com/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 릴리스](https://developers.cloudflare.com/changelog/post/2026-06-03-public-oauth-clients/)를 가능하게 함 - 데이터베이스 마이그레이션 중 관측된 주요 수치: - 업데이트된 행: **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 위에 통합을 구축할 수 있음 - 시작하려면 [문서](https://developers.cloudflare.com/fundamentals/oauth/)를 보거나 [대시보드](https://dash.cloudflare.com/?to=/:account/oauth-clients)의 OAuth apps 페이지에서 첫 OAuth 앱을 만들 수 있음 ## Comments ### Comment 60341 - Author: neo - Created: 2026-06-26T10:11:50+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48668033) - Ory Hydra 만든 사람임. 이 블로그 글과 기술 설명을 보니 정말 반갑고, 이 소프트웨어가 세계 인터넷 기업들을 보호하게 될 줄은 상상도 못 했음 **2.x 버전**이 그 규모에서 잘 동작한다니 좋고, CPU 사용량도 말도 안 되게 작아 보임 문제가 생기면 더 빠른 상용 버전도 있음. 자체 OAuth, IAM, ReBAC 권한, API 키, 에이전트 보안에 관심 있으면 오픈소스와 상용 제품을 [https://github.com/ory]()와 [https://www.ory.com/]()에서 볼 수 있음 - 예전에 dotnet용 identity server 프레임워크를 자체 호스팅으로 운영하면서 매달 수십억 요청을 처리했는데, 그 규모의 **OAuth와 OpenID Connect**는 사실상 해결된 문제에 가깝고 유지보수 부담도 낮았음 조직의 핵심 서비스였고 컴플라이언스도 강했지만, 담당 팀은 아마 3명 정도였고 지금도 잘 돌아감 이 프로토콜을 두고 왜 그렇게 혼란이 많은지 이해가 안 됐고, 같이 일한 거의 모든 주니어 엔지니어가 이해하는 데 어려움을 겪었음. Scott Brady의 블로그 [https://www.scottbrady.io/]()는 이 주제에서 큰 도움이 됨 인증/인가가 끼면 엔지니어들에게 원초적인 “두려움”이 생기는 듯함. 문제 해결에 익숙한데, 인증/인가는 그 문제 해결의 전제조건처럼 들어와서 인지 비용을 만든다고 봄 - dotnet용 identity server가 상용 제품으로 바뀌어서 사용 비용이 엄청 비싸진 그 제품인가? Lite도 연 **거의 6000달러**부터 시작함: [https://duendesoftware.com/pricing]() - 전형적인 Cloudflare임. 모두를 위해 잘 동작하고 그리 비싸지 않지만, 그 모든 장점의 결과로 **모든 것의 중심**에 자리 잡음 - Cloudflare는 기본 범위를 벗어나면 가장 비싼 제공자 중 하나임. **동영상 스트리밍** 가격을 보면 됨 - 그 정도면 공정한 거래 아닌가 싶음 - Grant임. Aeneas와 함께 **2.0 마이그레이션 코드** 대부분을 작성했음. Cloudflare 팀의 글에 감사함 “조사 결과, Hydra 마이그레이션 중 하나에 문제가 있어 일부 유효한 OAuth 세션의 상태가 손상됐고, 그 결과 마이그레이션이 해당 세션을 무효로 표시했다”는 부분이 오픈소스 마이그레이션 파일 중 하나였는지 궁금함 이제 프로젝트에 관여하지는 않지만, 업스트림에서 수정됐는지 알고 싶음 - 전체 맥락에는 최소한 Cloudflare 생태계 안에서의 **인가와 인증 흐름** 계획이 함께 들어가야 해서 감정이 복잡함. GitHub 예제도 없음 그래도 Cloudflare가 올바른 방향으로 출발한 것은 맞지만, 기반이 되는 Ory 전체 제품군과 비교하면 갈 길이 멂. Ory Kratos는 신원, 로그인, 등록, 복구, 다중 인증 등을 처리함: [https://github.com/ory]() 전체 범위에는 사용자 저장소, SAML, 다중 테넌트 조직 모델 계획도 들어가야 한다고 봄. 좋은 예로 Zitadel [https://github.com/zitadel]()은 조직 다중 테넌시용 관리 UI, OIDC/PKCE 지원 등을 제공하고 RBAC도 일부 붙일 수 있음 Supabase도 관리형 및 오픈소스 인증을 제공함: [https://github.com/supabase/auth]() “MCP는 죽었고 Skills가 영원하다”는 논외로, 이들 모두에서 MCP를 붙이고 키를 회전시키는 계획이 곧 크게 터질 것 같아 걱정됨 OAuth 2.0 동적 클라이언트 등록(RFC 7591): [https://datatracker.ietf.org/doc/html/rfc7591]() [https://modelcontextprotocol.io/specification/2025-03-26/bas...]() 특히 다중 테넌트 SaaS와 내장 **AI 어시스턴트** 맥락에서 의견을 듣고 싶음 - 최근 IAM 벤더와 MCP 서비스를 보호하는 작업을 해봤는데, 그 맥락에서 **OAuth 동적 클라이언트 등록**은 무섭게 느껴짐 MCP를 에이전트에 연결할 때 보통 쓰는 리다이렉트 흐름에서, 명세는 이를 어떻게 안전하게 만들지 거의 말하지 않음 아무나 임의의 콜백으로 클라이언트를 등록하게 하고 싶지는 않음. 그건 피싱에 노출되는 길임 악성 콜백 URL로 클라이언트를 등록한 뒤 사용자가 그 흐름을 시작하는 링크를 누르게 속이면, 합법적인 신원 제공자가 사용자를 인증한 다음 접근 토큰을 공격자에게 넘겨주게 됨 명세는 클라이언트가 등록 전에 먼저 얻는 초기 접근 토큰을 이야기하며 대충 넘기지만, 세부 사항은 부족하고 모든 최종 사용자가 클라이언트가 되는 상황에서는 아마 작동하기 어려움 이상적으로는 리다이렉트 패턴 허용 목록을 지정해서 ChatGPT 같은 대상으로 제한하고 싶음. 하지만 이는 비표준 동작이라 IAM 벤더가 서두르지 않음 - 여기서 의도가 뭔지 모르겠음. 좋게 끝날 세계가 없음. Cloudflare는 거의 인프라 제공자인데, 어떤 사용자가 자기 계정 권한을 제3자 클라이언트에 위임하게 하는 인프라용 모델은 **남용 가능성**이 큼 AWS 같은 회사가 하지 않는다면 그럴 만한 이유가 있다고 봄 - AWS가 정확히 이걸 함 예를 들어 IAM은 특정 저장소에서 실행되는 GitHub Actions에 Lambda 업데이트 권한을 줄 수 있음 - OAuth가 뭔지 이해하고 있음? API 키와 비슷하지만 남용될 가능성이 더 낮음. 좋은 일이고, 여러 방식으로 보안을 돕고 토큰을 들고 다니는 것보다 보안 흐름을 더 안전하게 만듦 - Google 사용자용 새 OAuth 클라이언트를 만들 수 있는 **Google 개발자 프로그램**과 얼마나 다른지 모르겠음 - OAuth와 엔터프라이즈 인증은 만들어진 것 중 최악일지도 모름. 클라우드를 다룰 때 가장 혼란스럽고 짜증나는 부분일 수 있음 AI 도구들도 브라우저를 열 수 있다고 가정하지 않고 헤드리스 시스템에서 기본 OAuth를 처리하는 데만 1년이 걸렸음 RBAC/IAM/워크로드 신원/서비스 계정 같은 대형 클라우드 제공자들의 온갖 인증 토끼굴로 내려갈 거라면, 개인 사용을 위한 단순한 방식은 제발 남겨두면 좋겠음 그냥 **API 키** 하나면 됨. 비밀로 보관하고 필요하면 폐기하면 되지, 모든 플랫폼의 모든 계층에 인증 잡동사니 1만 겹이 얽힐 필요는 없음 - OAuth가 **프라이버시** 맥락에서 거의 이야기되지 않는 이유를 모르겠음. OAuth 제공자는 사용자가 어떤 사이트에 언제 로그인하는지 모두 알게 됨 프라이버시 악몽임 - OAuth2는 복잡하고 종종 맞는 도구가 아님. Ory Hydra를 만들었고, OAuth2가 좋은 선택인 경우와 아닌 경우를 다룬 글도 썼음: [https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u...]() API 키용으로는 Ory Talos([https://github.com/ory/talos]())를 막 출시했음. OAuth2가 사용 사례에 비해 과한 경우에 좋은 대안임 OAuth2 사용을 정당화하는 사용 사례와 보안 우려도 있음. DPoP 같은 명세로 이런 흐름을 더 안전하게 만들 수 있음 여기서 제시된 사용 사례는 OAuth2에 적합해 보이지만, 모든 곳에 맞는 것은 아님. 복잡성은 시스템 보안을 더 어렵게 만듦 - 일반적인 로그인 흐름도 완전히 망가뜨린 느낌임. 보통 비밀번호 관리자가 사용자명과 비밀번호 필드를 자동 입력해줬는데, OAuth 때문에 사용자명 필드만 나오거나 “비밀번호로 로그인” 같은 버튼을 먼저 눌러야 하는 바보 같은 단계가 자주 생김 - 데이터상으로는 그 API 키를 비밀로 유지하는 데 실패할 가능성이 높고, 필요할 때 폐기하는 데도 실패할 가능성이 큼. 당연히 필요한 만큼 자주 회전하지도 않을 것임 **OAuth2/OIDC**의 장점은 신뢰를 API 키 소지자에게 두지 않고, 접근이 필요한 실제 신원에 둔다는 데 있음 - 그럼 애플리케이션에 직접 구현하면 됨. 임의 키를 생성하고 해시와 솔트를 저장하면 끝임 인증이 어렵다는 건 많은 사용자용 인증에 해당함. 자기 자신을 위한 인증은 아주 단순하고, 괜찮은 프레임워크를 쓰면 더 쉬워짐 구현이 불안하면 최신 모델 중 하나에 던져보면 됨. 그렇게 단순한 인증 시스템의 문제를 찾는 데는 꽤 잘함 - “Ory Enterprise License: CVE 보안 SLA, SAML, B2B 조직, 다중 테넌시, 더 나은 확장성 같은 엔터프라이즈급 기능을 해제” [0] 아니면 완전한 자체 호스팅 제품을 제공하는 **Keycloak**을 계속 쓰면 됨 [1] [0][https://github.com/ory]() [1][https://www.keycloak.org/]() - Keycloak은 예를 들어 내부 직원용으로 전체 Java 서버 스택을 운영하고 싶다면 훌륭하지만, Ory는 대규모 운영, 예컨대 OpenAI [https://www.ory.com/case-studies/openai]() 같은 사례와 조합 가능한 방식에서 훨씬 낫다고 봄 상용 버전이 있는 이유는 세계적인 오픈소스를 어떻게 재정적으로 지속하겠느냐는 문제 때문임. 지구상 가장 큰 소프트웨어 회사들을 받치는 오픈소스에 작동하는 사업 모델이 있다는 건 나쁜 일이 아니라 좋은 일임 참고로 IBM도 Keycloak으로 돈 받는 방법을 찾아냄 - 프로덕션에서 Keycloak을 다뤄봤는데 그리 훌륭하지 않음. 내부적으로 **Infinispan과 JGroups**를 쓰지 않았다면 나았을지도 모름. 둘 다 이유 없이 터무니없이 복잡함 - Keycloak임 - 이건 기본적으로 Cloudflare 계정 접근용 OAuth 이야기이지, 사용자 지정 앱을 위한 Cloudflare 호스팅 범용 “로그인” 류의 기능은 아님 - 나도 처음엔 후자를 떠올렸고, 무엇을 제공하는지 궁금했음 - OAuth가 무엇인지 이해했다고 생각했는데, 이 글은 헷갈림. 클라이언트별 접근 키를 제공하는 표준화된 프로토콜이라고 봤음 여기서 **자체 관리 OAuth**가 뭔가? 무엇에 대한 접근 권한이 부여되고, 클라이언트는 누구고, 파트너는 누구인지 설명이 필요함 - “이번 달 초, 고객이 Cloudflare API에 대한 위임 접근용 OAuth 클라이언트를 직접 만들고 관리하기 쉽게 하는 자체 관리 OAuth를 발표했다”는 의미임 자체 리소스 접근을 승인/거부하는 OAuth 시스템을 직접 호스팅하게 해주는 것임. Cloudflare가 X 조건에서 Y를 허용해주길 기다리는 대신 원하는 로직을 만들 수 있음 본질적으로 “Cloudflare에 로그인” → Cloudflare가 자체 관리 OAuth 사용을 확인 → 사용자의 OAuth로 리다이렉트 → Cloudflare가 응답을 신뢰 → 사용자가 승인하면 계정 접근을 허용하는 흐름임 - 기본적으로 자체 **인가 서버**를 호스팅할 수 있다는 뜻임