우리 서비스에 Refresh Token이 정말 필요할까?

소셜 로그인 기능을 구현하다 보면 마주하게 되는 단어가 있다.

바로 Access Token과 Refresh Token

많은 튜토리얼에서 Refresh Token을 DB에 저장하라고 가르치지만, 모든 서비스가 그럴 필요는 없다.

오히려 불필요한 저장 방식은 보안 리스크만 키울 수 있다.

이번 글에서는 서비스의 성격에 따른 OAuth 2.0 관리 정책의 차이점을 정리해보고자 한다.

1. 시나리오 A: "사용자가 서비스에 접속해 있는 동안만 권한이 필요해요"

(단순 로그인 및 실시간 데이터 조회 서비스 + 활동 기반 실시간 인증 방식)

사용자가 우리 서비스에 로그인해서 마이페이지를 보거나, 버튼을 눌러 본인의 구글 드라이브 파일 목록을 불러오는 경우이다.

핵심 로직: 사용자가 우리 서비스에 '로그인' 상태를 유지하는 것이 곧 구글 API 사용의 전제조건이다.
토큰 관리 전략:
- Silent Refresh(조용한 갱신): Access Token은 보통 1시간이면 만료되지만, 사용자가 페이지를 이동하거나 버튼을 클릭하는 등 '활동 중'이라면 서버가 백그라운드에서 Refresh Token을 사용해 새 Access Token을 받아오게 처리한다.
- 이를 통해 사용자는 1시간이 지나도 로그아웃되지 않고 끊김 없는 경험을 유지한다.
저장소: Refresh Token을 영구적인 DB보다는 서버 세션이나 Redis 같은 보안 세션 저장소에 보관한다.
유저가 브라우저를 완전히 끄고 세션이 만료되면 자연스럽게 권한도 소멸되게 설계한다.
장점: 구현이 상대적으로 간결하며, 유저가 활동을 멈추고 떠나면 토큰 권한도 사라지므로 보안 리스크가 적다.

(백그라운드 자동화 및 대행 서비스)

"새 이메일이 오면 슬랙으로 알림 보내기"나 "매일 새벽 구글 시트에 데이터 백업하기"처럼,
유저가 브라우저를 닫아도 서버가 돌아가야 하는 경우

핵심 로직: 유저의 '로그인 여부'와 상관없이 구글 서버에 접근할 수 있는 '영구 통행증'이 필요.
토큰 관리:
- 인증 시 access_type=offline 옵션을 주어 Refresh Token을 반드시 받도록 처리해야한다.
- Access Token이 만료되면 서버가 스스로 Refresh Token을 꺼내 새 토큰을 발급받는다.
저장소: RDB(Relational DB)에 안전하게 영구 저장해야함.
장점: 유저에게 최고의 편의성(자동화)을 제공할 수 있음.

"세션 유효기간을 무한대로 늘리면 되지 않는가?"라고 생각할 수 있지만 여기에는 문제가 있다.

Session은 '요청' 기반
Session은 브라우저의 '요청'이 있어야만 서버가 인식할 수 있다.
새벽 3시에 서버 혼자 돌아가는 스케줄러는 브라우저 요청이 없으므로 세션에 접근할 방법이 아예 없다.
메모리 과부하
모든 유저의 Refresh Token을 메모리(세션)에 무기한 들고 있는 것은 서버 자원을 낭비하며, 서버가 꺼지면 모든 세션정보가 날라가게되어 예약된 자동화 작업이 모두 실패하는 장애로 이어지게 된다.