Google OAuth: 갱신 토큰의 클라이언트 키 결합, 접근 토큰의 Bearer 유지

1. 오래 쓰는 자격 증명부터 보호한다

갱신 토큰(refresh token)은 새 접근 토큰을 발급받는 데 쓰는 장기 자격 증명이다. 접근 토큰(access token)은 서비스에 요청할 때 쓰는 자격 증명으로, 구글은 일반적인 유효 기간을 1시간 이하로 설명한다.

추가된 DPoP는 RFC 9449에 정의된 애플리케이션 계층 보안 방식이다. 클라이언트가 만든 공개 키와 개인 키 쌍에 토큰을 연결한다. 토큰이 입장권이라면 대응하는 개인 키는 소유자임을 증명하는 별도 열쇠인 셈이다. 토큰만 유출돼서는 재사용할 수 없게 한다.

구글은 이 연결을 갱신 토큰에만 적용한다. 새 접근 권한을 계속 얻는 통로를 보호해, 공격자가 훔친 자격 증명으로 장기간 사용자를 사칭하는 위험을 줄이려는 선택이다.

2. 호출마다 검증하는 비용은 피한다

접근 토큰은 가진 사람이 사용할 수 있는 Bearer 방식을 유지한다. 구글은 요청이 많은 API에서 매번 비대칭 서명을 검증하면 연산 부담과 지연, 확장 비용이 커진다고 설명한다. 이는 설계 근거이며, 성능을 수치로 비교한 측정 결과는 제시되지 않았다.

이익과 비용은 서로 다른 곳에 놓인다. 장기 자격 증명을 보호하면서 서비스 호출마다 소유 증명을 검증하는 부담은 피하지만, 클라이언트에는 키의 안전한 생성·보관과 증명 생성 책임이 추가된다. 기존 토큰 관리에 암호 연산과 저장 제약까지 고려해야 한다는 뜻이다.

3. 도입에는 증명 생성 경로가 필요하다

클라이언트는 키 생성 외에 시각 정보와 nonce라는 일회성 값을 엄격히 처리해야 한다. 요청 정보를 담는 클레임과 헤더를 정확히 구성하고, 소유 증명을 담은 JWT도 만들어야 한다. 단순히 토큰을 전송하는 기존 흐름에 이 처리가 더해진다.

발표문에는 구현 코드 예시가 제시되지 않았다. 구글은 별도의 도입 가이드와 구현을 돕는 SKILL.md 문서를 안내한다. 따라서 발표만으로 구체적인 요청 형식이나 라이브러리 사용법까지 확정할 수는 없다.

4. 중간 서버를 거쳐도 연결을 유지한다

구글은 RFC 9700의 갱신 토큰 보호 논의와 브라우저 앱 관련 표준 초안을 근거로 든다. 브라우저 전용 백엔드, 토큰 중계 백엔드, 브라우저 기반 클라이언트라는 세 모델에서 갱신 토큰에 소유자 제약을 적용하도록 권한다.

전송 계층에서 토큰을 묶는 mTLS는 클라우드 프록시나 부하 분산기에서 연결이 끝나거나 끊길 수 있다. 반면 DPoP는 요청 헤더 수준에서 작동한다. 구글은 이 특성이 여러 중간 서버를 거치는 에이전트 구조에도 유용하다고 설명한다.

5. 쿠키 보호와 에이전트 위임은 별도다

일반 웹 앱의 세션 쿠키는 이번 기능의 보호 대상이 아니다. 구글과 웹 인큐베이터 커뮤니티 그룹은 쿠키를 기기 하드웨어에 묶는 DBSC를 개발하고 있다. API 토큰과 브라우저 세션은 서로 보완하는 별도 보호가 필요하다는 설명이다.

에이전트 간 업무 위임도 주의할 지점이다. 일을 넘겨받은 에이전트는 앞선 에이전트의 개인 키 없이는 그를 대신해 소유 증명에 서명할 수 없다. 개인 키를 공유하는 것은 이 보안 방식의 원칙에 어긋난다.

소비자용 인증 엔드포인트인 oauth2.googleapis.com은 토큰 교환을 지원하지 않는다. 구글은 다중 에이전트나 연동 클라우드 작업에 Google Cloud Secure Token Service를 검토하라고 권한다. 중간 에이전트가 상위 토큰을 자기 키에 묶인 단기 연동 토큰으로 바꾸는 경로다.

이번 변경은 서비스 호출 방식은 유지하면서 장기 자격 증명을 강화하는 선택이며, 도입 판단의 핵심은 키 관리와 위임 경로를 감당할 수 있는지다.