Refresh Token 구조

 

 

 

Refresh Token은 한 줄로 말하면:

"짧게 사는 Access Token을
다시 발급받기 위한 장기 인증 토큰"

 

이다.

---

왜 필요하냐?

JWT의 가장 큰 문제는:

탈취되면 위험

 

이라는 것.

---

그래서 Access Token을 짧게 만든다

예:

토큰	만료시간
Access Token	15분
Refresh Token	14일

---

그런데 문제

사용자가:

15분마다 로그인

 

해야 하면 불편하다.

---

그래서 등장

Refresh Token

 

---

핵심 아이디어

짧은 Access Token
+
긴 Refresh Token

 

조합.

---

전체 흐름 먼저

1. 로그인
2. Access + Refresh 발급
3. Access로 API 사용
4. Access 만료
5. Refresh로 재발급
6. 새 Access 발급

 

---

STEP 1 — 로그인 성공

서버가:

• Access Token
• Refresh Token

둘 다 발급.

---

예시

Access Token

15분

 

---

Refresh Token

14일

 

---

STEP 2 — Access Token 사용

API 요청:

 

Authorization: Bearer ACCESS_TOKEN

 

---

STEP 3 — Access 만료

서버 응답:

 

401 Unauthorized

 

---

STEP 4 — Refresh Token 사용

클라이언트가:

"새 Access 주세요"

 

요청.

---

STEP 5 — 서버 검증

서버가:

Refresh Token 유효한가?

 

확인.

---

STEP 6 — 새 Access 발급

성공 시:

새 Access Token

 

발급.

사용자는 로그인 다시 안 해도 됨.

---

왜 이렇게 나누냐?

핵심은:

위험한 토큰은 짧게

 

다.

---

만약 Access 탈취되면?

공격자는 최대:

15분 정도만 사용 가능

 

---

즉 피해 제한 가능.

---

그럼 Refresh는 왜 길게?

Refresh는:

재로그인 방지

 

용도.

즉 UX 개선.

---

그런데 Refresh Token은 더 위험

왜냐면:

장기간 재발급 가능

 

하기 때문.

---

그래서 저장 위치 중요

실무에서는 보통:

HttpOnly Secure Cookie

 

많이 사용.

---

LocalStorage는 위험 가능

XSS 시 탈취 가능.

---

실무 핵심 — Refresh는 DB/Redis 저장

엄청 중요.

---

Access는 Stateless 가능

JWT 자체 검증.

---

하지만 Refresh는 보통 서버 저장

왜냐면:

• 강제 로그아웃
• 탈취 탐지
• 만료 관리

필요.

---

추천 구조

Redis 저장

예:

refresh:USER123
→ TOKEN_VALUE
→ expire=14d

 

---

왜 Redis 많이 쓰나?

• TTL 지원
• 빠름
• 만료 자동 처리

좋기 때문.

---

Refresh Rotation도 중요

현대 실무에서 매우 중요.

---

옛날 방식 문제

Refresh 하나 계속 사용.

---

문제

탈취되면:

오래 악용 가능

 

---

그래서 Rotation

재발급 시:

기존 Refresh 폐기
+
새 Refresh 발급

 

한다.

---

즉 구조

Refresh 1회 사용 후 교체

 

---

탈취 탐지도 가능

예:

이미 사용된 Refresh 재사용 발견

 

→ 계정 탈취 의심 가능.

---

실무 추천 구조

현재 가장 일반적.

---

Access Token

항목	추천
저장	메모리
만료	짧게(15m~1h)
서버 저장	보통 안 함

---

Refresh Token

항목	추천
저장	HttpOnly Cookie
서버 저장	Redis
Rotation	사용 권장

---

로그아웃 처리

Session 방식

세션 삭제

 

끝.

---

JWT 방식

보통:

Refresh 삭제

 

한다.

그러면 Access 만료 후 재발급 불가.

---

OAuth2에서도 동일

OAuth2도 사실:

Access + Refresh

 

구조 사용.

예:

• Google OAuth
• Kakao OAuth

---

Refresh 탈취가 더 위험

실무에서:

Access보다 Refresh 보호가 더 중요

 

하다고 보는 경우 많다.

---

핵심 한 줄

Refresh Token 구조는:

짧게 만료되는 Access Token을 안전하게 재발급하기 위해,
장기간 유지되는 Refresh Token을 별도로 관리하는 인증 구조

 

다.