[SW Engineering] JWT 기반 인증의 한계와 보안·제어성 개선 전략

JWT(JSON Web Token)는 서버의 확장성을 높여주는 강력한 도구이지만, Stateless(무상태성)라는 특징 때문에 **'즉시 로그아웃 처리'**와 **'토큰 탈취 위험'**이라는 태생적인 한계를 가집니다. 현재 운영 중인 시스템의 문제점을 분석하고, 이를 어떻게 해결했는지 정리해 보고자 합니다.

---

1. 현재 인증 아키텍처 (AS-IS)

기존에는 성능과 확장성을 고려하여 다음과 같이 설계했습니다.

• Access Token (AT): 클라이언트(JS 변수/Local Storage)가 관리. 무상태성 유지를 위해 DB에 저장하지 않음 (유효기간 15분).
• Refresh Token (RT): 보안 및 제어권 확보를 위해 서버 DB에 저장.
• 인증 방식: AT를 Authorization 헤더에 담아 전송.

---

2. 발견된 문제점 (Pain Points)

① 로그아웃의 불완전성 (제어권 부재)

사용자가 로그아웃을 요청하면 서버 DB에서 Refresh Token을 삭제합니다. 하지만 이미 발급된 Access Token은 유효기간이 만료될 때까지 서버에서 강제로 만료시킬 방법이 없습니다. 즉, 로그아웃 후에도 15분 동안은 탈취된 토큰으로 API 요청이 가능한 보안 홀이 발생합니다.

② XSS(Cross-Site Scripting) 공격 취약성

현재 토큰을 JSON 응답 바디로 전달하고 클라이언트가 이를 저장하고 있습니다. 이 경우, 공격자가 악의적인 스크립트를 삽입하면 document.cookie나 로컬 스토리지를 통해 토큰을 탈취할 수 있는 XSS 공격에 매우 취약합니다.

---

3. 해결 방안 (TO-BE)

해결책 1: Redis를 이용한 Blacklist 도입

Access Token의 Stateless함을 일부 포기하더라도 보안을 위해 로그아웃된 토큰을 관리해야 합니다.

• 방식: 로그아웃 시, 남은 유효시간만큼 Access Token을 **Redis(In-memory DB)**에 저장합니다.
• 검증: API 요청 시마다 Redis를 확인하여 해당 토큰이 Blacklist에 있다면 요청을 거절합니다.
• 이점: Redis는 조회 속도가 매우 빨라 성능 저하를 최소화하면서 즉각적인 로그아웃을 구현할 수 있습니다.

해결책 2: HttpOnly Cookie 적용

자바스크립트로 토큰에 접근하는 경로를 원천 차단합니다.

• 방식: 토큰을 응답 바디가 아닌 Set-Cookie 헤더를 통해 전달하며, HttpOnly 옵션을 설정합니다.
• 특징: 브라우저가 HTTP 요청 시 자동으로 쿠키를 포함하지만, JS 코드로 쿠키 값에 접근하는 것은 불가능해집니다. (XSS 방어)
• 추가 보안: Secure 옵션(HTTPS 전용)과 SameSite=Strict/Lax 옵션을 통해 CSRF 공격까지 예방합니다.

---

4. 정리 및 결론

문제점	원인	해결책
로그아웃 후에도 인증 유지	AT의 Stateless 특성	Redis Blacklist를 통한 강제 만료
토큰 탈취 위험(XSS)	JS로 접근 가능한 저장소 사용	HttpOnly Cookie 사용

"완벽한 보안은 없지만, 레이어를 하나씩 추가함으로써 공격 비용을 높이는 것이 중요하다."는 점을 다시금 깨달았습니다. 기술적인 편리함과 보안성 사이의 균형을 맞추기 위해 앞으로도 고민이 필요할 것 같습니다.