[JWT] - Access Token , Refresh Token 만료

Access Token / Refresh Token 만료는 어떻게 판단할까?

JWT 기반 인증을 사용하다 보면 의문점이 생긴다

“엑세스 토큰이나 리프레시 토큰이 만료됐는지 어떻게 알 수 있을까?

이 글에서는 실제 서비스 흐름을 기준으로 토큰 만료를 어떻게 판단하고 처리하는지 정리한다.

---

전체 인증 흐름

JWT 인증의 기본 흐름은 다음과 같다.

1. 사용자 로그인
2. 서버가 Access Token + Refresh Token 발급
3. 클라이언트는 API 요청 시 Access Token 전송
4. 서버는 Access Token 검증
5. 만료 시 Refresh Token 으로 재발급 시도
6. Refresh Token 도 만료되면 재로그인 요구

---

Access Token 만료

Access Token 은 보통 JWT 형식이며, 내부에 만료 시간(exp) 클레임이 포함되어 있다.

요청 흐름

1. 클라이언트가 API 요청
2. Authorization 헤더에 Access Token 포함
3. 서버의 인증 필터에서 JWT 파싱
4. 현재 시간과 exp 비교
5. 만료되었으면 예외(401) 발생

특징

• Access Token 은 stateless 상태
• DB 조회 없이 토큰 자체만으로 만료 여부 판단
• 만료되면 서버는 요청을 즉시 거부

---

Refresh Token 만료

Refresh Token 은 구현 방식에 따라 판단 방법이 달라진다.

JWT 인 경우

흐름

1. Access Token 만료로 401 발생
2. 클라이언트가 Refresh Token 전송
3. 서버가 JWT 파싱
4. exp 만료 여부 확인
5. 유효하면 Access Token 재발급

특징

• Access Token 과 동일하게 파싱해서 만료 여부 확인
• 서버에서 강제 무효화가 어려움

DB/Redis 에 저장하는 경우

흐름

1. Refresh Token 발급 시 Redis 에 저장
2. TTL(Time To Live) 설정
3. 재발급 요청 시 Redis 조회
4. 값이 없으면 → 만료 이거나 이미 삭제됨
5. 값이 있으면 → 재발급 진행

특징

• 만료 여부를 저장소 기준으로 판단
• 로그아웃 시 즉시 무효화 가능
• 토큰 탈취 대응 가능

---

정리

즉, Access Token 은 JWT 의 exp 클레임을 서버에서 파싱해 만료 여부를 판단하며, Refresh Token 은 JWT 방식이거나 DB/Redis 에 저장된 TTL 기준으로 만료 여부를 판단한다.

클라이언트는 서버의 401 응답을 통해 간접적으로 토큰 만료를 인지하고, Refresh Token 이 유효한 경우 Access Token 을 재발급받는다.

---

참고자료

https://inpa.tistory.com/entry/WEB-📚-Access-Token-Refresh-Token-원리-feat-JWT