Managed OAuth for Access: 내부 앱을 한 번의 클릭으로 에이전트 대응시키기

Cloudflare Access로 보호된 내부 앱은 사람에게는 익숙한 로그인 흐름이지만, 에이전트에게는 단순한 리다이렉트 장벽이었다. Cloudflare는 이를 해결하기 위해 Managed OAuth를 open beta로 공개했고, Access 앱에 한 번만 켜면 OAuth 2.0을 아는 에이전트가 자동으로 인증 경로를 찾고 토큰을 받아 사용할 수 있게 했다.

초기에는 Cloudflare 내부에서만 임시 우회책을 썼다. OpenCode의 web fetch 도구를 수정해 특정 도메인에서 cloudflared CLI를 통해 인증 흐름을 열고 JWT를 받아 요청에 붙였지만, 이제는 이 방식 대신 Access 자체가 OAuth 서버처럼 동작한다.

작동 방식은 표준 그대로다.

• 인증되지 않은 요청에는 www-authenticate 헤더를 돌려준다.
• 에이전트는 /.well-known/oauth-authorization-server에서 메타데이터를 찾는다.
• Dynamic Client Registration (RFC 7591) 으로 클라이언트를 등록한다.
• PKCE (RFC 7636) 기반 인증 흐름으로 사용자의 동의를 받는다.
• 승인 후 에이전트는 사용자에 귀속된 JWT를 받아 인증 요청을 보낸다.

Cloudflare는 이 흐름이 MCP와 같다고 설명한다. 이미 MCP 서버 포털에서 OAuth 서버 역할을 지원해 왔고, 이제 그 방식을 Access가 보호하는 웹 페이지, 웹 앱, REST API 전체로 확장했다.

핵심 메시지는 분명하다. 내부 앱을 에이전트 친화적으로 만들기 위해 매번 API, CLI, MCP 서버를 새로 갖출 필요는 없다. Access 앞에 두고 Managed OAuth만 켜면, 오래된 레거시 앱도 즉시 에이전트가 접근 가능한 형태로 바뀐다.

또한 Cloudflare는 서비스 계정과 정적 크레덴셜 의존을 경계한다. 에이전트의 모든 행위는 시작한 인간에게 추적 가능해야 하고, 에이전트는 그 사용자가 원래 가질 수 있는 권한만 가져야 한다는 원칙이다. 그래서 OAuth처럼 사용자-에이전트 관계를 표현할 수 있는 표준이 필요하다고 강조한다.

아울러 에이전트 툴도 바뀌어야 한다고 본다. 대부분의 web fetch 도구는 401/403과 www-authenticate 헤더를 받아도 별다른 처리를 하지 않지만, RFC 9728을 따르면 에이전트가 스스로 인증 서버를 발견하고 로그인 흐름을 밟을 수 있다. Cloudflare는 이를 OpenCode의 web fetch 도구에 적용한 draft pull request도 공개했다.

앞으로는 이 모델이 Cloudflare의 API, 그리고 여러 Cloudflare 계정에 걸친 Organizations beta와도 이어진다. 하나의 IdP를 여러 계정에 공유하는 방향까지 준비 중이며, 내부 앱과 에이전트의 연결을 더 넓게 표준화하려는 흐름이 이어지고 있다.