인증 정보를 저장하지 않습니다: TokFresh 제로 트러스트 아키텍처 원리
Steve Kang · 2026년 5월 5일
중요한 계정에 서드파티 도구를 연결할 때마다, 깊이 생각하지 않아도 우리는 신뢰에 관한 결정을 내리고 있습니다. 이 회사가 토큰을 유출하지 않고, 해킹당하지 않고, 동의 없이 권한을 재활용하지 않고, 어느 날 사라져서 인증 정보가 방치된 데이터베이스에 남지 않을 거라는 믿음입니다.
스케줄에 맞춰 API를 두드리는 게 전부인 도구치고는 요구하는 신뢰가 지나치게 큽니다. 그래서 TokFresh는 그런 신뢰를 아예 필요로 하지 않도록 설계했습니다.
일반적인 SaaS 패턴
대부분의 자동화 도구는 예측 가능한 형태를 따릅니다. 사용자가 인증하면 도구가 OAuth 토큰이나 API 키를 발급받고, 그 인증 정보는 보통 암호화된 상태로 도구 서버에 저장됩니다. 그 순간부터 도구의 백엔드는 필요할 때마다 저장된 인증 정보로 사용자를 대신해 동작합니다.
이 방식은 잘 작동하고, 많은 사용 사례에서 사실상 유일한 현실적 아키텍처입니다. 다만 인증 정보가 이제 두 곳에 존재합니다. 사용자 본인 계정, 그리고 누군가의 데이터베이스. 그 누군가가 해킹당하거나, 인수합병되거나, 직원이 이상한 짓을 하거나, 백업이 엉뚱한 곳에 흘러들어가면, 사용자는 아무 잘못 없이 인증 정보가 노출됩니다.
API에 핑을 보내는 게 전부인 도구에게 이 트레이드오프는 지나치게 불균형해 보였습니다. TokFresh의 가치는 토큰을 저장할 필요 자체가 없는 성격이라, 구조적으로 저장이 불가능하도록 설계했습니다.
TokFresh의 접근 방식: 토큰을 아예 보지 않습니다
실제 플로우입니다. 이 과정 어디에서도 토큰은 TokFresh가 통제하는 서버를 거쳐 저장되거나 읽히는 형태로 지나가지 않습니다.
1단계: 브라우저에서 Claude의 OAuth 플로우를 엽니다. Claude Code가 쓰는 것과 동일한 인증 플로우입니다. Anthropic 인증 페이지로 리디렉션되어 요청을 승인하면, 클로드가 authorization code를 담아 다시 리디렉션합니다. 이 교환은 브라우저와 Anthropic 서버 사이에서만 일어납니다.
2단계: PKCE를 사용해 브라우저가 코드를 토큰으로 교환합니다. 가장 핵심적인 부분입니다. authorization code를 실제 액세스·리프레시 토큰으로 교환하는 과정은 브라우저 안에서 PKCE로 일어납니다. TokFresh 서버는 이 교환에 관여하지 않습니다. 토큰을 받지도, 요청을 프록시하지도 않으며, 중간에서 가로챌 코드 경로 자체가 없습니다.
3단계: 토큰은 잠시 sessionStorage에 머무릅니다. 탭을 닫는 순간 지워지는 브라우저 저장소인 sessionStorage에 잠시 머무릅니다. TokFresh 쪽에는 이 데이터를 붙잡아둘 영속성 계층이 없고, 탭을 닫으면 사용자 쪽에도 아무것도 남지 않습니다.
4단계: 브라우저가 토큰을 사용자 본인의 Cloudflare 계정으로 직접 전송합니다. Cloudflare API로 브라우저가 토큰을 본인 계정 스토리지에 곧바로 기록합니다. TokFresh의 인증 정보가 아니라 본인의 Cloudflare 인증 정보로 인증되는, 브라우저와 Cloudflare 사이의 직접 연결입니다.
5단계: TokFresh 서버는 웹페이지 하나를 서빙했을 뿐입니다. 이게 관여하는 전부입니다. 클로드 토큰은 TokFresh가 통제하는 인프라를 거치지 않습니다. "받은 다음 저장 안 한다"는 식으로 말씀드리는 게 아니라, 애초에 구조적으로 토큰을 받는 일 자체가 없습니다.
PKCE란 무엇인가
PKCE는 Proof Key for Code Exchange의 약자로, 퍼블릭 클라이언트가 관여하는 OAuth 플로우의 특정 문제를 해결합니다. 퍼블릭 클라이언트란 전통적인 서버 사이드 백엔드처럼 비밀 정보를 안전하게 감출 수 없는 클라이언트, 예를 들어 브라우저 기반 앱을 말합니다.
표준 OAuth 플로우에서는 요청자 본인임을 증명하기 위해 authorization code와 함께 클라이언트 시크릿을 교환합니다. 브라우저 기반 앱은 시크릿을 안전하게 보관할 수 없습니다. 브라우저로 전달되는 건 개발자 도구를 여는 누구에게나 노출되기 때문입니다. PKCE는 클라이언트가 플로우 시작 전 code_verifier라는 무작위 값을 생성하고, 여기서 해시값인 code_challenge를 파생시켜 최초 인증 요청과 함께 전송하는 방식으로 이를 해결합니다.
authorization code를 토큰으로 교환할 시점에는 코드와 함께 원래의 code_verifier를 보냅니다. 인증 서버는 이 verifier를 해싱한 값이 앞서 받은 challenge와 같은지 확인합니다. 공격자가 전송 중인 authorization code를 가로채도, 원본 verifier가 없으면 교환을 완료할 수 없습니다. 코드 하나만으로는 쓸모가 없습니다.
이 메커니즘 덕분에 TokFresh는 백엔드 클라이언트 시크릿 없이도 브라우저에서 토큰 교환 전체를 처리하면서 보안을 약화시키지 않습니다. 모바일 앱과 싱글 페이지 애플리케이션이 같은 이유로 쓰는 메커니즘입니다.
토큰이 실제로 머무는 곳
브라우저가 토큰을 Cloudflare로 보내면, 토큰은 사용자 본인의 Cloudflare Secrets와 KV에 AES-256으로 암호화되어 안착합니다. 이건 사용자 계정이 한 줄의 로우로 들어간 TokFresh 관리 데이터베이스가 아니라, Cloudflare에서 다른 걸 돌릴 때 쓰는 바로 그 본인 클라우드 계정 안의 리소스입니다.
설정 과정에서 브라우저가 명시적으로 허용한 범위를 넘어서는 Cloudflare 계정 API 접근 권한은 없고, 저장된 시크릿을 이후에 읽을 수 있는 상시 인증 정보도 없습니다. 배포 후 TokFresh의 접근 권한을 완전히 철회해도 워커는 예전과 똑같이 돌아갑니다. 애초에 TokFresh와의 지속적인 연결에 의존한 적이 없기 때문입니다.
워커의 토큰 라이프사이클
배포가 완료되면 Cloudflare Worker는 사용자 계정 안에서 자체적으로 토큰 라이프사이클을 관리합니다.
- 워커가 Cloudflare KV에서 현재 리프레시 토큰을 읽습니다.
- 클로드의 OAuth 토큰 엔드포인트에서 이 리프레시 토큰을 새 액세스 토큰으로 교환합니다.
- 액세스 토큰으로 예약된 API 호출을 클로드에게 보냅니다.
- 클로드의 OAuth 플로우는 사용할 때마다 리프레시 토큰을 회전시키므로, 워커는 새 토큰을 KV에 다시 써넣어 기존 것을 교체합니다.
이 루프는 Cloudflare 인프라 내부, 사용자 계정 범위 안에서만 일어나며 외부 서버는 관여하지 않습니다. 이 사이클 어디에도 TokFresh 서버로의 콜백은 없습니다. 워커는 TokFresh에 접속하지도, 사용 현황을 보고하지도 않으며, 계속 작동하는 데 서버가 온라인일 필요도 없습니다.
감수한 트레이드오프
이런 방식으로 만드는 건 공짜가 아닙니다. 아무것도 저장하지 않기로 하면서, 많은 SaaS 제품이 당연하게 여기는 것들을 포기했습니다.
의미 있는 방식으로 활성 사용자 수를 세지 못합니다. 누가 워커를 배포했는지 추적하는 데이터베이스가 없으니까요. 초기화 이력을 보여주는 사용량 분석이나 대시보드도 제공할 수 없습니다. 그 이력은 TokFresh가 아니라 사용자 본인의 Cloudflare 계정에만 존재합니다. 이미 배포된 워커에 자동 업데이트를 밀어넣을 수도 없습니다. 워커가 돌아가기 시작한 이후로는 TokFresh와의 지속적인 연결이 없기 때문인데, 그래서 TokFresh는 직접 접근하지 않고도 워커가 스스로 설정을 가져올 수 있는 동적 설정 시스템을 포함합니다.
이런 건 실제 한계이고, 성장을 우선시하는 SaaS 회사라면 실수라고 말할 겁니다. 하지만 이건 유용한 일 하나를 해내고 조용히 물러나는 작은 도구에 걸맞은 선택이라고 생각합니다.
이게 왜 중요한가
TokFresh 서버가 내일 영영 사라진다 해도, 사용자의 워커는 계속 돌아갑니다. 토큰은 TokFresh 계정이 아니라 사용자 본인의 Cloudflare 계정에 있고, 크론 트리거·리프레시 로직·API 호출 전부 사용자가 통제하는 인프라 안에 존재하니까요. 유일하게 잃는 건 TokFresh 웹 인터페이스로 스케줄을 재설정하는 기능뿐이고, 코드가 오픈소스라 워커를 직접 수정해도 해결됩니다.
제로 트러스트 설계의 진짜 시험대는 벤더가 잘 행동하겠다고 약속하느냐가 아니라, 벤더가 완전히 사라져도 시스템이 작동하느냐입니다. TokFresh는 정책이 아니라 구조로 이 시험을 통과하도록 만들어졌습니다.