Cloudflare의 AI가 작성한 OAuth 라이브러리 살펴보기

2 weeks ago 8

Cloudflare OAuth 라이브러리의 개요

Cloudflare는 OAuth 프로바이더 라이브러리를 Anthropic의 Claude LLM을 활용해 대부분 자동으로 작성함
Claude의 출력물은 숙련된 Cloudflare 엔지니어들의 보안 및 표준 준수 검토를 거쳤으며, 커밋 히스토리에서 AI와의 상호작용 과정을 투명하게 공개함
초기 구현 후 Claude의 추가 프롬프트와 결과물 검토를 통해 퀄리티를 보완함
AI에만 의존하지 않고, RFC 문서와의 교차 점검 및 핵심 전문가 리뷰가 강조된다고 명시함

LLM 코딩 방식 특유로 코드가 단일 파일에 집중되어 있으나, 구조는 일관되고 쓸데없는 주석이 비교적 적음
기능 테스트는 있으나 OAuth와 같은 중요 인증 서비스에 요구되는 수준에는 미치지 못함
- 필수(MUST/MUST NOT) 사양 체크가 빠진 부분 및 파라미터 유효성 약화가 엿보임

HTTP 응답에 X-Content-Type-Options: nosniff 및 HTTP Strict Transport Security 등 핵심 보안 헤더 미적용 현상이 존재함
JSON API 특성상 일부 헤더의 필요성이 낮을 수 있으나, 클라이언트/브라우저 취약점 예방 차원에서 적용 필요성이 큼

Public client 지원을 위해 OAuth 2.1에서 폐기된 implicit grant 방식을 구현함
- 사실 해당 기능은 PKCE나 CORS 완화로 충분히 대체 가능
- Claude가 implicit grant를 추천한 것으로 보이며, 실제 토큰 발급 단계에서는 제대로 검증하지 않음
Basic Auth 처리 미흡: OAuth에서는 특유의 URL 인코딩 방식이 필요한데 이를 누락함
- 클라이언트 시크릿에 콜론 포함 시 발생할 수 있는 보안 버그 secondary issue
- 단, 해당 라이브러리는 자체적으로 클라이언트 ID/시크릿을 생성해 형식 통제가 가능한 구조임

토큰 ID 랜덤 문자열 생성 방법이 통계적으로 치우침(biased) 이 존재함
- 엔트로피 감소로 인해 공격이 용이해질 수 있으나, 실질적인 위협은 제한적임
"모든 코드 라인이 전문가에 의해 리뷰되었다"는 주장과 달리, 초기 커밋에서 버그가 그대로 존재
- 첫날 한 명의 개발자가 21번 메인 브랜치에 직접 커밋한 이력 등, 체계적 리뷰 부족을 암시함

토큰 저장소 암호화 설계는 사람이 주도하고, 구현은 Claude가 지원함
토큰별로 props를 암호화하고, 각 토큰에 대해 대칭키를 래핑하는 방식 적용
Claude가 중간에 잘못된 설계를 제안하자, 엔지니어가 의도와 보안 취지를 명확하게 제시하여 수정함
- 예시: SHA-256 해시를 래핑키로 사용할 경우 드러나는 취약점 지적 후 HMAC 기반으로 변경
- PBKDF2 제안에 대해 성능상 비효율을 짚고, 32바이트 HMAC 키 적용으로 조정함
이 과정은 AI와 작업할 때 높은 수준의 도메인 지식 필요성을 잘 보여줌
- 치명적 결함을 비전문가라면 인지조차 어려울 수 있음

첫 버전 임에도 완성도는 무난하나, 실 서비스에 바로 적용하기에는 위험성이 큼
OAuth 프로바이더 개발은 본질적으로 매우 까다로운 보안·기능 검증 작업이 필요함
- 대기업 수준의 수십만 개 자동화 테스트와 다계층 보안 점검이 일반적임
- LLM 기반 자동 코딩을 “쉽게” 적용할 수 있는 분야가 아님
프로젝트의 커밋 히스토리는 LLM이 어느 수준까지 보조적으로 작동할 수 있는지 흥미롭게 보여줌
- 단, 일부 결함은 LLM이나 사람 모두가 종종 범하는 실수이며, Stack Overflow 답변 등 기존 커뮤니티에서도 유사하게 발견됨
- 면밀함과 꼼꼼함이 중요한 코드 영역에서는 AI, 인간 모두 세밀한 주의가 필요함
LLM을 활용해 코드를 검토하거나 결과를 신뢰하려면, 직접 구현 경험 및 System 2 사고가 필수적임
- 단순/비핵심 작업에서는 충분히 LLM에 맡길 수 있지만, 인증이나 보안과 관련된 주요 시스템은 전문가 주도의 설계·구현이 바람직함