Access Token vs Refresh Token

보안의 대장정을 지나 이제 실무 운영의 묘미인 Access Token과 Refresh Token의 관계까지 왔습니다.

이 두 토큰의 관계는 한마디로 "보안과 편의성 사이의 완벽한 밀당"이라고 할 수 있습니다. 왜 하나만 쓰지 않고 굳이 두 개를 쓰는지 아주 자세히 파헤쳐 볼게요.

---

1. Access Token (출입증)

"지금 바로 문을 열 수 있는 실제 열쇠"

• 역할: 서버의 자원(데이터)에 접근하기 위해 매번 보여줘야 하는 토큰입니다.
• 특징:
• 수명이 매우 짧습니다. (보통 30분 ~ 1시간)
• 사용자가 요청을 보낼 때마다 HTTP 헤더에 실려 나가기 때문에, 탈취당할 위험이 가장 큽니다.
• 서버는 이 토큰이 오면 "유효기간이 남았나? 서명이 맞나?"만 확인하고 바로 통과시켜 줍니다.

2. Refresh Token (열쇠 재발급권)

"열쇠가 만료되었을 때, 새 열쇠를 받을 수 있는 권한"

• 역할: Access Token이 만료되었을 때, 다시 로그인(ID/PW 입력)하지 않고도 새로운 Access Token을 발급받기 위해 사용합니다.
• 특징:
• 수명이 매우 깁니다. (보통 2주 ~ 한 달)
• 평소에는 통신에 사용되지 않고, 오직 '재발급' 시에만 서버로 전송됩니다. 그래서 탈취 위험이 훨씬 적습니다.
• 서버는 보통 이 토큰 정보를 DB에 저장해두고 관리합니다. (나중에 강제로 로그아웃시키기 위해!)

---

🔄 토큰의 순환 과정 (Flow)

사용자가 앱을 쓰는 동안 뒤에서는 이런 일이 일어납니다.

1. 로그인 성공: 서버가 XX님께 Access(1시간)와 Refresh(2주) 토큰을 둘 다 줍니다.
2. API 요청: XX님은 Access Token만 들고 신나게 서비스를 이용합니다.
3. 만료 발생: 1시간이 지나 Access Token이 죽었습니다. 서버가 401 Unauthorized 에러를 보냅니다.
4. 재발급 요청: 앱(클라이언트)은 당황하지 않고, 주머니 속에 있던 Refresh Token을 꺼내 서버에 보냅니다. "나 이거 있는데, 새 열쇠 좀 줘!"
5. 새 열쇠 지급: 서버는 DB에서 Refresh Token을 확인하고, 문제가 없으면 새로운 Access Token을 발급해줍니다.
6. 무한 반복: XX님은 로그인 창을 다시 본 적이 없는데, 실제로는 열쇠가 계속 갈아 끼워지고 있는 것이죠!

---

3. 왜 이렇게 번거롭게 두 개를 써요? (보안의 핵심)

이게 이해하셔야 할 핵심 포인트입니다.

• 만약 Access Token만 길게(2주) 쓴다면?
  해커가 중간에 토큰을 가로채는 순간, 2주 동안 XX님 계정은 해커의 놀이터가 됩니다. 서버는 토큰이 유효하기 때문에 막을 방법이 없습니다.
• 두 개를 같이 쓰면?
  Access Token을 뺏겨도 1시간만 지나면 무용지물이 됩니다. 해커가 새 열쇠를 받으려 해도 Refresh Token은 해커에게 없기 때문에 더 이상 침입할 수 없습니다.

---

📊 Access vs Refresh 한눈에 비교

구분	Access Token	Refresh Token
수명	매우 짧음 (30분~1시간)	매우 김 (2주~한 달)
전송 빈도	매 요청마다 전송 (위험 노출↑)	재발급 시에만 전송 (위험 노출↓)
저장 장소	브라우저 메모리 / 로컬 스토리지	안전한 HTTP-only 쿠키 / DB
목적	자원 접근 (Access)	Access Token 재발급

---

🔗 다음 공부의 연결고리

여기서 아주 날카로운 질문이 하나 나올 수 있습니다.

"그럼 만약 해커가 아주 운 좋게 Refresh Token까지 훔쳐 가면 어떡해? 그럼 2주 동안 털리는 건 똑같잖아!"

이 치명적인 상황을 막기 위해 등장한 기술이 바로 [Refresh Token Rotation (회전)]과 [Blacklist] 기법입니다.