Chiko IT
클라우드 & SaaS

Cloudflare OAuth 무료 공개 — Auth0·Keycloak 대체 가능한가

Chiko
11min read

목차

Cloudflare workers-oauth-provider가 정확히 어떤 도구인가

결국, Cloudflare가 2025년 들어 workers-oauth-provider라는 라이브러리를 MIT 라이선스로 공개했다. Workers 환경에서 OAuth 2.1 인가 서버를 구현할 수 있게 해주는 모듈이다. (출처: GitHub cloudflare/workers-oauth-provider, 2025-04)

그런데, 요점부터 짚으면 IdP(Identity Provider) 전체를 통째로 제공하는 게 아니다. 인가 코드 발급, 액세스 토큰 발급, refresh 흐름, 토큰 폐기 같은 OAuth 2.1 표준의 서버 측 책임을 KV·Durable Objects 위에서 처리해주는 SDK에 가깝다. 사용자 식별·로그인 UI·MFA·이상 탐지는 별도로 붙여야 한다.

또한, 처음 발표를 봤을 때 헷갈렸던 건 이걸 "Auth0 대체"라고 부르는 게 맞느냐였다. Auth0가 들고 있는 기능 셋과 비교하면 노출 면적이 훨씬 좁다. 다만 OAuth 서버를 직접 운영해야 하는 팀, 특히 MCP 서버나 외부 개발자용 API 게이트웨이를 만드는 팀에는 의미가 다르다. 표준 준수와 인프라 비용 두 가지가 한꺼번에 풀린다.

문제 정의 — 기존 OAuth 인프라의 비용·운영 부담

게다가, OAuth 서버를 직접 들고 있어야 하는 워크로드는 생각보다 많다. 외부 개발자 콘솔, 모바일 앱의 자체 백엔드, 파트너사용 API, 그리고 최근에는 MCP 서버까지. 이 모든 경우에 발급기·검증기 한 쌍이 필요하다.

문제는 풀세트 IAM(Auth0·Okta 같은)이 이 좁은 요구사항에 비해 과하게 비싸다는 점이다. Auth0 B2B 플랜은 2026-06 기준 월 1,000 MAU 이하 무료지만, M2M(Machine-to-Machine) 토큰은 별도 과금 대상이다. 토큰 발급 1,000건당 가격이 붙고, API 트래픽이 늘수록 부담이 빠르게 누적된다. (출처: Auth0 Pricing, 2026-06 기준)

그래서, 반대편의 Keycloak은 셀프 호스트라 라이선스 비용은 없지만 운영 책임을 통째로 떠안는다. Realm·Client·Mapper 모델을 익혀야 하고, PostgreSQL과 세션 캐시까지 직접 관리한다. Quarkus 기반으로 바뀐 Keycloak 24 이후로 메모리 사용량은 줄었지만 초기 부팅 시간과 설정 학습 곡선은 여전히 가파르다. (출처: Keycloak 24 Release Notes)

특히, 이 사이에 끼인 영역이 있다. "사용자 인증은 이미 다른 곳에 있고, 우리는 OAuth 발급기만 필요하다"는 케이스다. workers-oauth-provider가 정확히 이 자리를 노린다.

기존 접근의 한계 — Auth0와 Keycloak의 경계

세 도구를 같은 표 안에 넣어보면 가치 제안이 어떻게 갈리는지가 더 분명해진다.

항목 Auth0 Keycloak workers-oauth-provider
형태 SaaS 셀프 호스트(JVM) 라이브러리(Workers)
라이선스 상용 Apache 2.0 MIT
가격(2026-06 기준) MAU·M2M 별도 과금 인프라 비용만 Workers 요청당
사용자 DB 내장 내장 직접 구현/위임
MFA·이상 탐지 내장 Realm 설정 없음
SAML·SCIM 지원 지원 없음
OAuth 2.1·PKCE 옵션 옵션 기본값 강제

여기서 보이는 게 두 가지다. 첫째, Auth0와 Keycloak은 IAM(Identity and Access Management) 전체를 책임지는 풀세트다. 둘째, workers-oauth-provider는 OAuth 표준의 서버 측만 가져간 좁은 도구다. 둘은 서로 직접 경쟁한다기보다, 시장 자체가 갈라지는 쪽에 가깝다.

Auth0의 M2M 과금 구조가 만드는 비용 곡선

그래서, Auth0의 가격이 비싸지는 지점은 사용자 수가 아니라 M2M 토큰 발급량이다. 서버 간 통신을 OAuth로 묶어 둔 시스템은 분 단위로 토큰을 갱신한다. 이 트래픽이 다 과금 단위에 들어간다. 한 팀의 사례를 일반화해 말하긴 어렵지만, M2M 토큰만 분리해 옮기는 것만으로 인증 비용의 절반 이상이 빠진다는 보고가 여러 곳에서 공유된 적이 있다.

Keycloak의 운영 부채

따라서, Keycloak은 자유롭지만 운영비가 인프라로 환산돼 돌아온다. 작은 t3.small 한 대에 PostgreSQL + Keycloak을 올리면 월 30~50달러 선이지만, 가용성을 위해 다중화·세션 복제·백업·업그레이드 절차까지 더하면 SRE 시간이 적지 않게 든다. "잘 되면 안 건드린다"는 원칙이 가장 어울리는 도구지만, 한번 업그레이드가 밀리면 OAuth 표준 변경을 따라가기가 부담스러워진다.

제안 — workers-oauth-provider의 설계 의도

그래서, 이 라이브러리의 핵심 설계 결정 두 가지를 살펴볼 만하다.

첫째, OAuth 2.1과 PKCE를 기본값으로 강제한다. 보안적으로 위험한 Implicit Flow나 Password Grant는 아예 노출되지 않는다. 이건 RFC 9126(Pushed Authorization Requests), RFC 9728(Protected Resource Metadata) 같은 최신 표준을 적극 반영한 설계로 보인다. (출처: Cloudflare 블로그 "Open-sourcing our OAuth Provider", 2025)

그런데, 둘째, 토큰 저장소가 Workers KV다. KV는 글로벌 엣지에 캐싱되기 때문에 토큰 검증 요청이 사용자 가까운 엣지에서 끝난다. 기존에 Auth0 토큰을 검증하려면 JWKS 캐싱 + 백엔드 검증 로직이 필요했지만, 이 모델은 엣지가 발급과 검증을 함께 가져간다.

실제로, 코드 노출 면적은 작다.

// workers-oauth-provider 사용 예시 (단순화)
import { OAuthProvider } from "@cloudflare/workers-oauth-provider";

export default new OAuthProvider({
  apiRoute: "/api/",                 // 보호할 경로
  apiHandler: ApiHandler,            // 토큰 검증 통과 후 실행
  defaultHandler: UiHandler,         // 로그인·동의 화면 등
  authorizeEndpoint: "/authorize",
  tokenEndpoint: "/token",
  clientRegistrationEndpoint: "/register",
  // 토큰 서명 키 알고리즘 — 운영에서는 ES256/EdDSA 권장
  accessTokenTTL: 60 * 60,
  refreshTokenTTL: 60 * 60 * 24 * 30,
});

그러나, 이 코드 자체는 단순하다. 무게는 UiHandler 안쪽에 들어간다. 실제 로그인 UI, 비밀번호 검증, MFA, 사용자 DB 조회—이 부분을 직접 구현하거나 외부 IdP에 위임해야 한다. 이 지점이 도입 난이도를 결정한다.

특히 MCP(Model Context Protocol) 서버를 만드는 경우에 잘 맞는다. MCP 사양 자체가 OAuth 2.1 기반 인가를 요구하기 때문이다. Cloudflare가 자사 MCP 서버 가이드에서 이 라이브러리를 권장하는 이유다.

검증 — 실제 운영 항목 단위로 본 차이

비용 절감만 보고 옮기면 후회한다. 운영 항목을 다 펼쳐놓고 따져야 한다. 네 가지가 중요하다.

토큰 발급 지연

그래서, Auth0의 /oauth/token 응답 시간은 리전 기준 보통 100~300ms 사이다. (출처: Auth0 Status Page 과거 기록) workers-oauth-provider는 엣지에서 처리되므로 RTT 자체는 짧을 가능성이 높다. 다만 KV는 쓰기 일관성이 eventual하다. 토큰 발급 직후 다른 리전에서 즉시 검증하려 하면 캐시 미스가 날 수 있다. 이런 경로는 Durable Objects처럼 강한 일관성이 보장되는 저장소로 보완해야 한다.

사용자 관리·MFA·이상 탐지

Auth0가 들고 있는 진짜 가치는 OAuth 서버가 아니다. 그 위의 사용자 DB, MFA, 비밀번호 정책, 봇 탐지, Brute Force 방어 같은 보안 운영이 핵심이다. workers-oauth-provider는 여기까지 책임지지 않는다. 이걸 대체하려면 별도로 구현하거나 WorkOS·Stytch 같은 IdP에 위임해야 한다. B2C 서비스 전체를 옮기는 게 망설여지는 진짜 이유가 여기 있다.

컴플라이언스 보고서

SOC 2·HIPAA·GDPR 보고서를 고객사에 제출해야 하는 B2B SaaS라면 Auth0의 인증서 패키지가 강하다. Cloudflare는 인프라 차원의 인증은 갖췄지만, "OAuth 서버를 직접 운영한 책임"은 본인이 짊어진다. 감사 로그도 Workers 분석 도구에 직접 적재해야 하고, Auth0 대시보드 같은 즉시 가시성은 없다.

키 알고리즘과 비용

특히, Workers는 요청당 CPU 시간이 제한된다. 무료 플랜은 10ms, 유료는 50ms~30s 사이로 조정 가능하다. JWT 서명·검증에서 RS256은 ECDSA 대비 CPU를 더 먹는다. 키 알고리즘을 ES256이나 EdDSA로 잡으면 토큰 발급 비용이 눈에 띄게 줄어든다. 이건 운영 들어가기 전에 결정해야 하는 항목이다.

한계점 — 어디서 대체되고 어디서 막히나

여기까지 본 내용을 종합하면 결이 보인다.

반면, 대체가 자연스러운 케이스가 있다. 외부 개발자에게 API를 여는 게이트웨이용 OAuth 서버, MCP 서버의 인가 계층, 그리고 이미 사용자 인증은 다른 IdP에 위임돼 있고 발급기만 필요한 구조. 이런 영역에서는 Auth0의 M2M 요금을 빠르게 줄일 수 있고, Keycloak처럼 인프라 운영 부담을 지지 않아도 된다.

반대로 막히는 케이스도 분명하다. B2C 로그인 전반(소셜 로그인 + 비밀번호 + MFA + 이상 탐지)은 풀세트 IAM이 여전히 유리하다. SAML·SCIM 기반 엔터프라이즈 SSO를 받아야 하는 SaaS도 마찬가지다. workers-oauth-provider는 OAuth 2.1 표준에 집중한 도구이지, IAM 전체를 대신하지 않는다.

Workers KV의 글로벌 전파 지연

또한, 가장 분명한 운영상 한계 하나는 KV 쓰기 전파다. KV 쓰기는 글로벌 전파에 수초가 걸린다고 Cloudflare 본인들이 문서에 명시한다. (출처: Workers KV 문서, "Eventual Consistency" 섹션) 토큰 발급 직후 다른 리전 검증이 필요한 흐름은 반드시 Durable Objects나 D1으로 보완해야 한다. 이걸 모르고 들어가면 "왜 토큰을 방금 받았는데 검증이 안 되나" 같은 시행착오를 만난다.

사용자 DB를 위임할 곳을 먼저 정해야 한다

특히, 라이브러리 자체에는 사용자 모델이 없다. PoC 단계에서는 KV에 간단한 사용자 레코드를 두고 시작해도 되지만, 운영에서는 D1·외부 DB·외부 IdP 중 하나를 골라야 한다. 이 결정을 뒤로 미루면 마이그레이션 비용이 커진다.

개인 의견

그러나, 당장 실행할 수 있는 액션이 세 가지 있다.

  • 현재 운영 중인 OAuth 사용처를 M2M, B2C, 엔터프라이즈 SSO로 분류한다.
  • M2M만 따로 떼어 workers-oauth-provider로 PoC를 돌려본다. Workers 무료 플랜 안에서 충분히 검증된다.
  • 토큰 키를 ES256 또는 EdDSA로 잡고, 강한 일관성이 필요한 경로는 Durable Objects를 끼워둔다.

개인적으로는 인증 인프라를 한 곳에 몰아넣던 시대가 끝나가는 것 같다. Auth0·Keycloak이 풀세트 IAM을 책임지고, 그 옆에 엣지 OAuth 서버가 좁고 빠른 영역을 가져가는 분업 구조가 더 자연스러워 보인다.

관련 글

More posts