Access Token과 Refresh Token 작동 방식
Source: Dev.to

간단한 로그인 흐름

- “Google로 로그인”을 요청합니다.
- 앱이 인증 서버(Google)로 리디렉션되고, 인증 서버가 사용자를 인증한 뒤 인증 코드를 반환합니다.
- 앱은 해당 코드를 액세스 토큰(및 리프레시 토큰)으로 교환합니다.
- 앱은 액세스 토큰을 사용해 리소스 서버를 대신 호출합니다.
인증 서버는 누구인지를 담당하고, 리소스 서버는 무엇을 할 수 있는지를 담당합니다.
액세스 토큰
액세스 토큰을 일일 이용권으로 생각하면 됩니다. 모든 리소스 서버 요청에 이 토큰이 포함되며, 서버는 응답하기 전에 토큰을 검증합니다.
- 단기간 유효 – 보통 몇 분에서 몇 시간 정도.
- 자주 노출 – 거의 모든 요청에 포함되므로, 짧은 수명은 탈취 시 피해를 제한합니다.
오래 지속되는 액세스 토큰은 보안 재앙이 됩니다. 공격자가 오랜 기간 동안 이를 사용할 수 있기 때문입니다.
리프레시 토큰
액세스 토큰이 만료되면, 앱은 리프레시 토큰을 사용해 인증 서버로부터 새로운 액세스 토큰을 조용히 받아옵니다. 사용자와의 상호작용은 필요 없습니다.
- 장기간 유효 – 며칠, 몇 주, 혹은 몇 달까지.
- 거의 전송되지 않음 – 인증 서버에만 전송되고, 리소스 서버에는 절대 전송되지 않음.
- 목적이 명확 – 새로운 액세스 토큰을 얻는 용도에만 사용됩니다.
이러한 분리 덕분에 리프레시 토큰을 더 안전하게 보관할 수 있고, 필요 시 중앙에서 쉽게 폐기할 수 있습니다.
빠른 비교

| 구분 | 액세스 토큰 | 리프레시 토큰 |
|---|---|---|
| 수명 | 몇 분‑몇 시간 | 며칠‑몇 달 |
| 노출 | 모든 API 요청에 포함됨 | 인증 서버에만 전송 |
| 목적 | 리소스 접근 권한 부여 | 새로운 액세스 토큰 획득 |
| 폐기 | 보통 짧은 수명이라 영향 적음 | 중앙에서 쉽게 폐기 가능 |
단일 토큰만 사용하면 안 되는 이유
모든 요청에 장기간 유효한 단일 토큰을 사용한다면 보안 재앙이 됩니다. 토큰이 탈취되면 공격자는 오랜 기간 동안 제한 없이 접근할 수 있습니다. 역할을 나누면:
- 액세스 토큰 – 짧은 수명으로 노출 위험을 최소화.
- 리프레시 토큰 – 오래 지속되지만 거의 노출되지 않으며, 폐기가 용이.