📌 [JWT 인증 시스템 시리즈 - 4편] AccessToken + RefreshToken 저장 및 재발급 흐름 + 예외 상황 정리

📅 날짜

2025-05-20

---

📝 학습 내용

1️⃣ RefreshToken 저장이 필요한 이유

AccessToken은 보통 짧은 수명을 가지며, 클라이언트는 만료 시 RefreshToken을 통해 다시 인증해야 한다.

그렇기 때문에 RefreshToken을 서버에 저장해두는 것이 중요하다.

✅ 서버(DB)에 RefreshToken을 저장하면:

• 🛡️ 탈취 여부 확인 가능: 공격자가 임의로 만든 RefreshToken은 서버에서 확인 가능
• 🔁 불필요한 재로그인 방지: AccessToken만 만료된 경우, 다시 로그인할 필요 없이 새로 발급 가능
• 🔒 로그아웃 시 강제 만료 가능: 서버에서 해당 사용자의 토큰을 제거하면 자동 로그아웃 효과

🔗 이 흐름을 위해 JwtToken 테이블에 AccessToken + RefreshToken을 함께 저장한다.

---

2️⃣ 전체 인증 흐름 요약

단계	설명
로그인 성공	AccessToken + RefreshToken 생성
AccessToken → 클라이언트	쿠키에 저장 (HttpOnly, Secure 적용 가능)
RefreshToken → 서버	DB(JwtToken Entity)에 저장
인증 요청	클라이언트가 AccessToken을 헤더로 전송
AccessToken 만료	클라이언트가 RefreshToken과 함께 /refresh 요청
RefreshToken 검증 성공	새로운 AccessToken 발급 및 쿠키 갱신
RefreshToken 만료 or 없음	전체 재로그인 요구

---

3️⃣ JwtToken Entity 구조

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
@Entity
public class JwtToken {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name="accessToken", columnDefinition = "TEXT", nullable = false)
    private String accessToken;

    @Column(name="refreshToken", columnDefinition = "TEXT", nullable = false)
    private String refreshToken;

    @Column(name="username", nullable = false)
    private String username;

    @Column(name="createAt", nullable = false)
    private LocalDateTime createAt;
}

---

4️⃣ JwtToken 저장 흐름 (로그인 성공 시)

@Slf4j
@Component
public class CustomSuccessHandler implements AuthenticationSuccessHandler {

    @Autowired
    private JwtTokenProvider jwtTokenProvider;

    @Autowired
    private JwtTokenRepository jwtTokenRepository;

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
                                        Authentication authentication) throws IOException, ServletException {

        TokenInfo tokenInfo = jwtTokenProvider.generateToken(authentication);

        // AccessToken → 쿠키로 클라이언트 전달
        Cookie cookie = new Cookie(JwtProperties.ACCESS_TOKEN_COOKIE_NAME, tokenInfo.getAccessToken());
        cookie.setMaxAge(JwtProperties.REFRESH_TOKEN_EXPIRATION_TIME);
        cookie.setPath("/");
        response.addCookie(cookie);

        // AccessToken + RefreshToken → DB 저장
        JwtToken jwtToken = JwtToken.builder()
                .accessToken(tokenInfo.getAccessToken())
                .refreshToken(tokenInfo.getRefreshToken())
                .username(authentication.getName())
                .createAt(LocalDateTime.now())
                .build();
        jwtTokenRepository.save(jwtToken);

        response.sendRedirect(request.getContextPath() + "/");
    }
}

---

5️⃣ AccessToken 만료 시 처리 흐름 (Refresh 기반 재발급)

🧭 기본 흐름

1. 클라이언트는 AccessToken이 만료되었음을 감지
2. 서버에 /refresh 요청을 보냄 (RefreshToken 포함)
3. 서버는 DB에서 해당 사용자의 RefreshToken 조회
4. RefreshToken 유효하면 새로운 AccessToken 발급 → 쿠키로 전달
5. 기존 AccessToken은 폐기하거나 그대로 둠

---

🧩 예외 상황 정리

상황	설명	처리 전략 (예정)
✅ 최초 로그인(Client: AT ❌ / DB: ❌)	새로 발급해서 클라이언트 전달 + DB 저장	정상 흐름
✅ 기존 로그인(Client: AT ✅ / DB: ✅)	토큰 유효 시 문제 없음	정상 흐름
🔁 AccessToken 만료 / RefreshToken 존재	/refresh 요청 통해 재발급	새로운 AT 발급
⚠️ AccessToken 만료 / RefreshToken 없음	재로그인 필요	로그인 페이지로 리다이렉트
❌ Client: AT ❌ / DB: ✅	쿠키 제거되거나 만료된 경우	Refresh로 인증 가능 / 없으면 로그인 유도
🧨 RefreshToken 조작됨 or 탈취됨	보안 위험	서버에서 차단 후 전체 세션 로그아웃 필요 (블랙리스트 등 활용 예정)

---

🔥 정리

구성요소	설명
JwtToken Entity	Access/RefreshToken과 사용자 정보를 함께 저장
CustomSuccessHandler	로그인 성공 시 토큰 발급 및 저장 처리
JwtTokenRepository	DB에서 토큰 조회 및 관리
/refresh (추후 구현)	AccessToken 재발급 처리 엔드포인트 예정
예외처리 전략	상황별 흐름을 분기하여 대응 설계 가능

---

🔗 참고 자료

• RFC 6749 – OAuth 2.0
• Spring Security JWT 재발급 흐름 예시
• JWT 보안 가이드 (OWASP)

---

🧠 느낀 점

• RefreshToken을 저장하고 인증 흐름을 분리해서 설계하니, 보안성과 사용자 편의성이 동시에 높아짐
• 예외 상황을 직접 그려보니 실무에서 예상치 못한 흐름까지 고려하게 됐고, /refresh API 설계에 더 확신을 가질 수 있었다
• 이후에는 Redis 기반 저장소, 토큰 블랙리스트, 사용자 강제 로그아웃 등도 구현해보고 싶다

---

✅ 요약

• JWT 인증 구조에서 AccessToken과 RefreshToken을 분리 저장함으로써 인증 흐름을 더 유연하게 제어할 수 있다.
• RefreshToken을 저장하면 탈취 탐지, 재로그인 최소화, 서버 측 만료 제어 등이 가능하다.
• 예외 상황을 사전에 정의하고 설계하면, 사용자 경험과 보안을 모두 챙길 수 있다.

---