Google OAuth가 DPoP로 리프레시 토큰을 클라이언트 키에 묶습니다, MCP·에이전트 연동 팀이 먼저 볼 변화 | DAKER 커뮤니티

OAuth 리프레시 토큰은 한 번 털리면 공격자가 새 액세스 토큰을 계속 받아 갈 수 있다는 점에서 가장 오래 위험이 남는 자격 증명입니다. Google은 2026년 10월 15일 개발자 블로그에서 Google OAuth가 DPoP(Demonstrating Proof-of-Possession)를 지원한다고 발표했습니다. 리프레시 토큰을 클라이언트가 만든 비대칭 키 쌍에 암호학적으로 묶어, 토큰이 유출되더라도 개인 키 없이는 재사용할 수 없게 만드는 방식입니다. 이 글은 10월 16일 기준으로 공식 발표와 도입 가이드를 확인해, Google API를 연동하는 한국 개발팀과 MCP·에이전트 서비스를 만드는 팀이 알아야 할 변화를 정리합니다.

DPoP가 막으려는 공격

공식 글은 기존 Bearer 토큰을 주운 사람이 임자인 구조라고 설명합니다. RedLine이나 NodeStealer 같은 인포스틸러 악성코드가 개발자 PC나 서버에서 토큰을 빼 가거나, 중간자 공격으로 토큰을 가로채면 공격자는 그 토큰을 그대로 들고 API를 호출할 수 있습니다. DPoP는 RFC 9449로 표준화된 OAuth 2.0 보안 프로파일로, 요청마다 클라이언트 개인 키로 서명한 증명(DPoP proof JWT)을 함께 보내게 해 토큰 탈취와 재전송을 무력화합니다.

Google은 수명이 긴 리프레시 토큰만 DPoP로 묶고, 1시간 이하의 짧은 액세스 토큰은 기존 Bearer 방식으로 둡니다. 보안과 API 응답 속도 사이에서 고른 절충입니다.

왜 리프레시 토큰에만 적용했나

Google의 설명은 규모의 문제입니다. Gmail, Calendar, Drive처럼 호출량이 많은 API에서 매 요청마다 ES256 같은 비대칭 서명을 검증하면 API 게이트웨이의 연산 부담과 지연이 크게 늘어납니다. 그래서 무기한으로 새 액세스 토큰을 받을 수 있는 리프레시 토큰만 키에 묶고, 짧게 만료되는 액세스 토큰은 그대로 두어 대부분의 API 호출에는 추가 검증 비용이 들지 않게 했습니다. 공식 글은 유출된 리프레시 토큰이 공격자에게 쓸모없어진다는 점을 핵심 효과로 꼽습니다.

대신 개발 쪽 부담은 늘어납니다. 클라이언트에서 키를 생성하고 안전하게 보관해야 하며, 타임스탬프와 nonce 처리, htm·htu·iat·jti 클레임 계산, 정확한 헤더 구성과 증명 JWT 생성까지 직접 챙겨야 합니다. Google은 구현을 돕기 위해 DPoP 도입용 SKILL.md도 함께 제공한다고 밝혔습니다.

MCP와 멀티 에이전트 구조에서 달라지는 점

공식 글은 DPoP가 HTTP 헤더 수준에서 동작하기 때문에, 클라우드 프록시나 로드밸런서에서 끊기기 쉬운 mTLS 기반 토큰 바인딩보다 여러 단계를 거치는 MCP·자율 에이전트 구조에 잘 맞는다고 설명합니다. 다만 에이전트 A가 작업을 에이전트 B에 넘기고 B가 리소스를 호출하는 위임 구조에서는 B가 A의 개인 키 없이 증명을 만들 수 없습니다. Google의 소비자용 OAuth 엔드포인트는 토큰 교환 표준(RFC 8693)을 지원하지 않으므로, 이런 구조라면 Google Cloud Secure Token Service(STS)로 상위 토큰을 중간 에이전트 자신의 키에 묶인 단기 토큰으로 바꾸라고 권합니다.

범위도 정확히 알아 두어야 합니다. DPoP는 웹 서비스의 세션 쿠키를 보호하지 않습니다. 쿠키 탈취는 Google과 WICG가 개발 중인 기기 바인딩 세션 자격 증명(DBSC)이 다루는 영역이라고 공식 글은 구분합니다.

한국 개발팀의 점검 순서

Google Workspace 데이터를 읽는 사내 자동화, 캘린더·메일 연동 SaaS, Google 계정으로 로그인하는 에이전트 서비스를 운영한다면 서버에 장기 보관 중인 리프레시 토큰부터 목록으로 만드는 것이 첫 단계입니다. 그다음 백엔드 프런트엔드 분리(BFF) 구조인지, 브라우저가 직접 토큰을 다루는지에 따라 키 보관 위치를 정하고, 도입 가이드 https://developers.google.com/identity/protocols/oauth2/resources/dpop-adoption를 따라 테스트 클라이언트부터 적용해 보는 것이 안전합니다. 발표 원문은 https://developers.googleblog.com/announcing-dpop-support-for-google-oauth-securing-refresh-tokens/입니다.

여러분의 서비스는 Google 리프레시 토큰을 어디에, 얼마나 오래 보관하고 있나요? DPoP를 붙인다면 어떤 부분이 가장 걱정되는지 댓글로 나눠 주세요.