요즘 면접에서 “JWT 탈취 시 대처 방안?” 같은 질문을 정말 많이 받는다. 보안 이슈가 중요해지다 보니, 인증/인가 관련 질문 비중도 점점 커지는 느낌이다. 나도 처음에는 이 질문이 너무 막막해서 힘들었던 경험이 있다. 정답이 딱 정해져 있는 주제도 아니고, 상황마다 대응이 달라지기 때문이다.
그래서 이번 기회에 내가 생각하고 정리한 내용을 한번 기록해보려고 한다.

📌 JWT

우리는 프로젝트를 할 때 JWT(JSON Web Token)을 정말 많이 사용한다. 쿠키 기반 인증은 속도는 빠르지만 보안에 취약하고, 세션 기반 인증은 서버에 세션을 저장해야 해서 자원을 많이 사용한다. 그런 이유들 때문에 요즘엔 JWT를 선호하는 분위기다. 솔직히 말하면, 많은 개발자들이 “요즘 트렌드가 JWT니까!” 하면서 일단 쓰고 본다. 나 역시도 처음에는 제대로 이해하지 않은 채, 그냥 다들 쓰니까 따라서 사용했던 게 사실이다. 그런데 문득 이런 생각이 들었다. 도대체 JWT가 뭐길래 이렇게 모두가 사용하는 걸까? 그게 보안적으로 완벽한 존재인가? 아니면 단순히 서버 자원을 아끼기 위한 수단일 뿐인가? 그래서 이번에는 그동안 가볍게만 알고 넘어갔던 JWT에 대해 직접 정리해보고 제대로 이해해보려고 한다.

일단 HTTP의 특성부터 짚고 넘어가자. 우리가 흔히 알고 있듯이 HTTP는 Stateless하고 Connectionless한 특징을 가지고 있다.

한마디로 말하면, 서버는 요청(Request)이 들어올 때마다 그때그때 응답(Response)을 보내줄 뿐, 클라이언트가 누구였고 어떤 상태였는지를 기억하지 않는다는 것이다. 또한 요청이 끝나면 연결을 유지하지 않기 때문에 지속적으로 연결되어 있는 상태도 아니다.

따라서 이걸 해결해주는 것이 무엇이냐? 바로 쿠키(Cookie)와 세션(Session)이다.

쿠키(Cookie)

쿠키(Cookie)란, 웹사이트가 사용자의 브라우저에 저장하는 작은 데이터 파일을 말한다.

Set-Cookie: userName=kevin; password=abc123

로그인 요청에 대해 서버는 응답 헤더에 Set-Cookie를 담아 사용자 정보를 클라이언트에 전달한다.

그 이후 사용자는 모든 요청마다 쿠키를 함께 전송하고, 서버는 해당 쿠키 값으로 사용자를 식별할 수 있다.

하지만 쿠키 방식에는 분명한 단점이 있다.

보안에 취약

• 쿠키 값이 탈취되거나 조작될 위험이 있다. (특히 비밀번호 같은 민감 정보는 절대 담아서는 안 된다)

• 저장 용량 제한 존재

• 브라우저 간 공유 불가

• 쿠키 크기가 커지면 네트워크 부하 증가

즉, 클라이언트에 중요한 정보를 저장한다는 것 자체가 위험하다는 근본적 한계를 가지고 있다.

세션(Session)

쿠키만으로 클라이언트의 로그인 상태를 유지할 수 있었지만, 가장 큰 단점은 쿠키가 탈취되거나 조작될 위험이 있다는 점이다. 특히, 민감한 개인정보를 HTTP로 주고받는 것은 매우 위험하다.

이를 보완하기 위해 세션(Session) 방식이 등장했다. 세션은 비밀번호 등 중요한 인증 정보를 서버 측에 저장하고, 클라이언트에는 세션 ID만 쿠키로 전달한다.

HTTP/1.1 200
Set-Cookie: JSESSIONID=FDB5E30BF20045E8A9AAFC788383680C;

서버는 로그인 요청 시 인증 정보를 서버에 저장하고, 클라이언트에는 식별용 세션 ID(JSESSIONID)를 쿠키에 담아 전달한다.

이후 클라이언트는 요청할 때마다 JSESSIONID 쿠키를 함께 전송하고, 서버는 이를 확인해 클라이언트를 식별한다.

장점

• 세션 ID만 전달되므로, 쿠키가 노출되어도 중요한 개인정보는 안전하다.

• 각 사용자마다 고유 세션 ID가 발급되므로, 요청 시 회원정보를 쉽게 확인 가능하다.

단점

• 세션 ID가 탈취되면, 공격자가 클라이언트인 척 위장할 수 있다.

• 서버에 세션 정보를 저장해야 하므로, 사용자 요청이 많아지면 서버 부하와 확장성 문제가 발생한다.

JWT 기반 인증

앞서 살펴본 쿠키/세션 기반 인증은 각각 장점이 있지만, 동시에 한계도 존재한다.

• 쿠키: 클라이언트에 민감 정보를 담을 경우 보안에 취약

• 세션: 서버에 인증 정보를 저장해야 하므로 서버 부하 및 확장성 문제 발생

이러한 문제를 개선하고자 등장한 것이 JWT(Json Web Token, JWT) 기반 인증이다.

JWT(JSON Web Token)란 인증에 필요한 정보를 암호화시켜 토큰 형태로 전달하는 방식이다. JWT 기반 인증은 쿠키/세션 방식과 마찬가지로 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별한다.

특히 JWT는 서버에 상태 정보를 저장하지 않아도 되는 Stateless 구조이므로, 분산 환경(예: 여러 대의 서버, 클라우드 환경)에서 뛰어난 확장성을 제공한다.

세션 방식은 모든 서버가 동일한 세션 저장소를 공유해야 하거나, Sticky Session같은 기술을 사용해야 하지만, JWT는 토큰 자체에 인증 정보를 담고 있기 때문에 서버 간 상태 동기화가 필요 없고, 새로운 서버를 추가해도 별도 세션 관리 없이 바로 인증 처리가 가능하다.

즉, JWT는 Stateless + 분산 환경 적합성 때문에, 현대 웹 서비스에서 확장성과 성능을 동시에 잡을 수 있는 인증 방식으로 각광받는다.

JWT 구조

JWT는 . (dot) 구분자로 이루어진 세 가지 문자열로 구성되며, 실제 구조는 다음과 같다.

1. Header

• JWT의 메타데이터를 담는 부분
• 주로 토큰 타입과 서명 알고리즘 정보를 포함한다
• alg: 토큰의 서명(Signature)을 생성할 때 사용하는 해싱 알고리즘 (예: HS256, RS256 등)
• typ: 토큰의 타입. 항상 "JWT"로 설정

Header는 단순히 정보를 담는 부분이며, 보안과 관련된 내용은 Signature에서 처리된다.

2. Payload

• JWT의 실제 데이터 영역

• 클라이언트와 서버가 인증을 위해 필요로 하는 정보를 담는다

• 각 key-value 쌍을 Claim이라고 부른다.

🚨 주의: Payload는 인코딩만 되어 있을 뿐 암호화되지 않음 ⇒ 누구나 Base64로 디코딩 가능하므로 민감한 정보는 절대 넣으면 안 된다.

3. Signature

• Header와 Payload를 비밀키(secret key)로 조합하여 해싱(Signature)한 값
• 서버는 이를 통해 토큰이 변조되지 않았는지 확인
• Signature 검증을 통해 토큰 위변조 여부 확인 가능
• Header와 Payload는 단순 인코딩만 되어 있어 누구나 읽을 수 있지만,
• Signature는 서버가 관리하는 비밀키가 없으면 위조할 수 없다.

즉, JWT의 보안 핵심은 Signature에 있으며, 서버는 토큰 자체를 저장하지 않고도 유효성을 검증할 수 있다.

어떻게 인증할까?

1. 로그인 요청

• 클라이언트가 사용자 이름/비밀번호 등으로 로그인 요청을 보낸다.

2. 서버 검증 및 토큰 발급

• 서버는 사용자를 검증한 후, 고유 ID, 권한, 만료 시간 등 필요한 정보를 Payload에 담는다.

• 비밀키(secret key)를 사용해 Header와 Payload를 조합하고 서명(Signature)을 만들어 JWT 토큰(Access Token)을 발급한다.

3. 클라이언트 토큰 저장

• 클라이언트는 발급받은 JWT를 로컬 스토리지, 세션 스토리지, 또는 쿠키 등에 안전하게 저장한다.

4. 토큰 포함 요청

• 클라이언트는 서버에 요청할 때마다, JWT를 HTTP 요청 헤더 Authorization에 포함시켜 보낸다.

Authorization: Bearer <JWT>

5. 서버 검증

• 서버는 전달받은 JWT의 Signature를 비밀키로 검증한다.
• 위변조 여부, 만료 여부 등을 확인하고, 유효하면 Payload의 정보를 사용해 요청을 처리한다.

6. 요청 처리

• 토큰이 유효하다면, 서버는 요청에 응답한다.

• 토큰이 유효하지 않거나 변조되었다면, 인증 오류를 반환한다.

⚡ 핵심 포인트: 서버는 JWT 자체를 저장하지 않아도 유효성을 검증할 수 있으므로 Stateless 인증이 가능하다.
이는 서버 확장성 측면에서 큰 장점이다.

JWT 토큰은 어디에 저장해야할까?

사실 이 부분에 대해서는 정답이 없다. 저장 위치마다 장단점이 있기 때문이다.

JWT를 저장하는 대표적인 4가지 방식이 존재한다. LocalStorage, SessionStorage, Cookie, 메모리(In-Memory) 에 저장하는 방식이 있다.

LocalStorage

LocalStorage는 브라우저에 데이터를 영구적으로 저장할 수 있는 공간이다. JWT를 LocalStorage에 저장하면 접근이 매우 쉽고 구현이 간단하다는 장점이 있다.

하지만 보안 측면에서는 취약하다. 웹 페이지에 악성 스크립트가 삽입될 경우(XSS 공격), 저장된 토큰을 쉽게 탈취할 수 있기 때문이다. 따라서 민감한 정보를 담거나 보안이 중요한 서비스에서는 주의가 필요하다.

SessionStorage

SessionStorage는 브라우저 탭 단위로 데이터를 저장하며, 브라우저나 탭을 닫으면 자동으로 삭제된다. LocalStorage보다 비교적 안전하고, SPA(Single Page Application) 환경에서 편리하게 사용할 수 있다.

하지만 새로고침 시 데이터가 사라진다는 단점이 있어, 사용성 측면에서는 다소 불편할 수 있다. 보안 측면에서는 LocalStorage와 마찬가지로 XSS 공격에 취약하다.

Cookie

쿠키는 브라우저가 자동으로 요청 시 전송할 수 있는 저장 방식이다. HttpOnly와 Secure 옵션을 사용하면 스크립트에서 접근할 수 없으므로 XSS 공격을 방지할 수 있다. 또한, 서버와 자동으로 토큰을 주고받을 수 있어 구현이 편리하다.

하지만 쿠키는 CSRF 공격에 취약하며, 크기 제한이 있고 서버 설정이 필요하다는 단점이 있다. 그래서 민감한 서비스에서는 CSRF 대응 전략을 함께 사용해야 한다.

메모리(In-Memory)

메모리 저장 방식은 브라우저의 자바스크립트 변수에 JWT를 저장하는 방법이다. 브라우저 새로고침 시 토큰이 사라지기 때문에, 탈취 위험을 최소화할 수 있다. SPA 환경에서는 페이지 이동 시에도 유지할 수 있어 UX 측면에서 비교적 편리하다.

하지만 새로고침 시 토큰이 초기화되므로 사용자 경험이 불편해질 수 있다. 그리고 브라우저를 종료하면 토큰이 사라지므로 장기 인증에는 적합하지 않다.

그래서 어디에 저장하라고?

아직 나도 취업준비생이고, 현업에서는 JWT를 어떻게 사용하는지 직접 경험해보진 못했지만, 개인 프로젝트나 학습을 하면서는 보통 이렇게 나누어 사용한다:

• Access Token → 메모리(In-Memory)
  Access Token은 주로 짧은 시간 동안만 사용되기 때문에, 브라우저 메모리에 저장해도 충분하다. 메모리에만 저장하면 XSS 공격 시 토큰 탈취 위험을 줄일 수 있으며, 페이지를 새로고침하면 자동으로 초기화되어 보안성이 높다.

• Refresh Token → HttpOnly Cookie
  Refresh Token은 Access Token을 재발급받는 데 사용되므로 상대적으로 장기간 저장된다. HttpOnly Cookie에 저장하면 스크립트에서 접근할 수 없어 XSS 공격을 방지할 수 있고, Secure 옵션과 HTTPS를 함께 사용하면 안전하게 서버와 통신할 수 있다. 또한, 서버에서 DB나 Redis 등 저장소에 토큰 상태를 관리하며 검증하거나 블랙리스트 처리를 통해 탈취 시 대응할 수도 있다.

Refresh Token 전략

JWT 기반 인증에서 Access Token은 비교적 짧은 만료 시간을 가지지만, Refresh Token은 상대적으로 장기간 유효하며 Access Token을 재발급 받는 용도로 사용된다. 따라서 Refresh Token을 안전하게 관리하는 전략이 매우 중요하다.

Refresh Token Rotation(RTR)

RTR는 “Refresh Token을 재사용할 때마다 새로운 Refresh Token을 발급하고, 이전 토큰은 무효화하는 전략”을 말한다.

이 방식은 특히 Refresh Token 탈취 공격(Replay Attack)에 대비하기 위해 사용된다.

⚠️ 공격 시나리오(왜 RTR가 필요?)

• 공격자가 사용자의 Refresh Token을 탈취했다고 가정

• 사용자는 정상적으로 Access Token 재발급 요청

• 서버는 새로운 Refresh Token을 발급하고, 기존 Token을 무효화

• 공격자가 탈취한 Token을 사용하려 하면?
  → 서버 DB/Redis에서 이미 사용된 토큰으로 판정 → 즉시 차단
  → 계정 탈취로 이어지는 것을 방지

즉, 토큰이 한 번이라도 사용되면 재사용 불가하므로
토큰 탈취 후 재사용(Replay)을 원천 봉쇄할 수 있다.

블랙리스트(Blacklist) 전략

블랙리스트 전략은 더 이상 유효하지 않아야 하는 Refresh Token 또는 Access Token을 서버에 기록해두고, 해당 토큰의 사용을 차단하는 방법이다.

JWT는 기본적으로 Stateless라 토큰 자체만 유효하면 서버 검증을 통과한다. 하지만 로그아웃, 토큰 회전(RTR), 탈취 등의 상황에서는 특정 토큰을 즉시 무효화해야 한다.

이때 서버 저장소(DB/Redis)에 무효 처리된 토큰 목록을 기록해두는 것이 블랙리스트 전략이다.

🚫 공격 시나리오(왜 블랙리스트가 필요?)

• 공격자가 사용자의 토큰(Access/Refresh Token)을 탈취했다고 가정

• 사용자가 로그아웃을 하거나, 비정상 접근이 감지되어 해당 토큰을 무효화 처리

• 무효화된 토큰이 DB/Redis의 블랙리스트에 등록

• 공격자가 탈취한 토큰으로 요청을 시도하면?
  → 서버가 JWT 검증 과정에서 블랙리스트를 조회
  → 이미 무효 처리된 토큰으로 판정 → 즉시 인증 실패
  → 추가적인 권한 상승 또는 계정 탈취 방지

즉, 만료 전 토큰이라도 블랙리스트에 등록되면 절대 사용할 수 없다. 이는 로그아웃 / 탈취 / 회전 시 즉시 사용자 보호가 가능하다는 의미다.

Redis를 많이 쓰는 이유

JWT 기반 인증을 쓰는 프로젝트가 많아지면서, 많은 사람들이 Redis를 많이 사용한다. 그 이유가 뭘까? 🤔

매 요청 검증 속도가 빠르다
블랙리스트나 Refresh Token 상태는 모든 인증 요청에서 확인해야 한다. DB를 매번 조회하면 지연이 생기지만, Redis는 메모리 기반이라 초고속 조회가 가능하다.

TTL(만료 시간) 관리가 쉽다
토큰은 만료 시간이 있기 때문에, Redis에 TTL을 설정하면 자동으로 만료 처리된다. 별도의 정리 작업이 필요 없어 실무에서 편리하다.

Refresh Token Rotation(RTR)과 궁합이 좋다
토큰 재발급 시 이전 토큰을 즉시 무효화해야 하는데, Redis는 읽기/쓰기 속도가 빠르기 때문에 즉시 반영 가능하다.

분산 서버 환경에서도 안정적이다
서버를 여러 대 운영하더라도 Redis를 중앙 캐시처럼 쓰면 모든 서버가 토큰 상태를 공유할 수 있어, 수평 확장 환경에서도 문제 없다.

다른 캐시도 사용 가능할까?

Redis가 많이 쓰이긴 하지만, 조건만 맞으면 다른 캐시 솔루션도 쓸 수 있다.

1. Caffeine Cache

• JVM 내부 메모리 기반 캐시

• 조회 속도는 매우 빠르지만, 분산 환경에서 상태 공유 불가

• 단일 서버 환경에서는 충분히 사용 가능

2. Memcached 등 네트워크 기반 캐시

• Redis와 유사하게 분산 환경에서 상태 공유 가능

• TTL 관리, 동시 접근 성능 고려 가능

💡 정리

• 단일 서버 + 단순 토큰 관리 → Caffeine Cache 가능
• 분산 서버 + 실시간 블랙리스트/Refresh Token 상태 공유 필요 → Redis 추천

---

🧹 정리

JWT 탈취 시 대응 방안

JWT는 Stateless라 토큰을 서버에서 강제로 무효화할 수 없기 때문에, 탈취를 완전히 차단하는 것이 아니라 피해를 최소화하는 방식으로 설계하는 것이 핵심이다.

Access Token과 Refresh Token의 역할이 다르기 때문에 대응 방법도 다르게 가져간다.

1) Access Token 탈취 시 대응

Access Token은 짧은 만료 시간을 가지기 때문에
피해를 최소화하는 전략을 사용한다.

• 만료 시간을 짧게 설정 (5~15분)
  → 탈취되어도 사용 가능한 시간이 제한됨.

• 비정상 사용 탐지(IP / UA / 지역 변화 감지)
  → 동일 토큰이 갑자기 다른 환경에서 사용되면 의심 요청으로 판단해 Redis 블랙리스트에 등록하여 즉시 차단한다.

• Refresh Token 재발급 시 연관된 Access Token 폐기
  → RTR 도중 사용된 Access Token을 블랙리스트에 넣어 확산을 막는다.

결론적으로 Access Token은 즉시 무효화는 어렵지만,
“짧은 만료 + 이상행위 차단”으로 피해 구간을 최소화한다.

2) Refresh Token 탈취 시 대응

• Refresh Token은 장기 권한을 가지기 때문에 보안이 훨씬 중요하고, 무조건 서버 저장소(DB/Redis)로 관리한다.

• 그리고 Refresh Token Rotation(RTR) 전략을 사용한다.

RTR 동작 방식

• 클라이언트가 Refresh Token으로 재발급 요청

• 서버는 새로운 Refresh Token을 발급

• 이전 Refresh Token은 Redis/DB에서 즉시 무효화

탈취 상황에서의 효과

• 공격자가 훔친 토큰으로 재발급을 시도하면,
  이전 토큰이 이미 사용된 기록이 있어 바로 차단(Replayed Token Detection), 동시에 사용자 계정을 보호하기 위해 Refresh Token 전체 무효화, 로그아웃 강제, 사용자에게 재로그인 요구

3) 결론: JWT 탈취 대응의 핵심

• Access Token: 피해 최소화(짧은 TTL + 블랙리스트 + 비정상 탐지)

• Refresh Token: RTR로 재사용 불가 + 서버 저장소 기반 강제 폐기

추가 보안: HttpOnly 쿠키 사용, TLS 강제, 토큰 누출 지점 최소화

핵심은 “JWT는 무효화가 어렵기 때문에,
애초에 탈취 전제로 설계하고, 피해를 최소화하는 흐름을 만든다.

---

참고

[Tecoble]인증 방식 : Cookie & Session vs JWT