[JWT] 5. JWT 실전 팁과 면접 대비

지금까지 세션의 한계, Stateless 인증, JWT의 구조, 서명 원리를 살펴봤다. 마지막 편에서는 실무에서 흔히 저지르는 실수, Refresh Token 전략, 보안 공격 대응, 그리고 면접에서 자주 나오는 질문을 다룬다.

자주 하는 실수

Secret Key를 코드에 하드코딩

개발 중에는 편하지만, 코드가 Git에 올라가는 순간 키가 노출된다.

// 위험 — 키가 코드에 노출됨
private static final String SECRET = "mySecretKey123";

// 안전 — 환경 변수에서 로드
@Value("${jwt.secret}")
private String secret;

Secret Key가 Git 히스토리에 한 번이라도 올라갔다면, 키를 변경해야 한다. git rm으로 파일을 삭제해도 히스토리에는 남아 있기 때문이다.

Payload에 너무 많은 정보

토큰은 모든 HTTP 요청의 헤더에 포함된다. Payload가 커지면 매 요청의 트래픽이 그만큼 증가한다.

// 과도한 Payload — 불필요하게 큰 토큰
{
  "user_id": 1,
  "email": "user@example.com",
  "name": "김철수",
  "phone": "010-1234-5678",
  "address": "서울시 강남구 ...",
  "profile_image": "https://cdn.example.com/...",
  "permissions": ["read", "write", "delete", "admin", ...],
  "login_history": [...]
}

// 적절한 Payload — 인증/인가에 필요한 최소 정보
{
  "sub": "user@example.com",
  "user_id": 1,
  "role": "USER",
  "iat": 1669996400,
  "exp": 1670000000
}

원칙은 간단하다. 인증과 인가에 꼭 필요한 정보만 넣는다. 프로필 이미지나 주소 같은 건 필요할 때 DB에서 조회하면 된다.

만료 시간을 너무 길게 설정

Access Token의 만료 시간을 며칠 단위로 설정하면, 토큰이 탈취되었을 때 그 기간 동안 아무런 대응을 할 수 없다. JWT는 발급 후 서버에서 강제로 무효화할 수 없다는 점을 항상 기억해야 한다.

// 위험 — 7일짜리 Access Token
.setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600000))

// 권장 — 30분짜리 Access Token + Refresh Token 전략
.setExpiration(new Date(System.currentTimeMillis() + 30 * 60 * 1000))

보통 Access Token은 15분~1시간 정도가 적절하다. 이렇게 짧게 설정하면 사용자가 자주 재로그인해야 하는 불편함이 생기는데, 이걸 해결하는 게 Refresh Token이다.

Refresh Token 전략

Access Token을 짧게 유지하면서도 사용자 경험을 해치지 않으려면, 두 종류의 토큰을 함께 사용한다.

• Access Token — API 요청에 사용하는 짧은 수명의 토큰 (15분~1시간)
• Refresh Token — Access Token을 재발급받기 위한 긴 수명의 토큰 (7일~30일)

이 방식의 핵심은 역할 분리다.

• Access Token이 탈취되면? 30분이면 만료되니까 피해 범위가 제한된다
• Refresh Token이 탈취되면? 이건 심각하다. 그래서 Refresh Token은 더 안전하게 관리해야 한다

Refresh Token 보관 위치

Access Token은 보통 메모리(JavaScript 변수)에 둔다. 페이지를 새로고침하면 사라지지만, XSS 공격으로부터 비교적 안전하다.

Refresh Token은 HttpOnly 쿠키에 저장하는 것이 일반적이다. JavaScript에서 접근할 수 없으니 XSS에 안전하고, 브라우저가 자동으로 전송하니 구현도 간편하다.

보안 공격과 대응

alg: none 공격

JWT의 alg 필드를 "none"으로 설정하면 서명 없이 토큰을 만들 수 있다. 오래된 라이브러리 중에는 이걸 허용하는 경우가 있었다.

// 공격자가 만든 Header
{
  "alg": "none",
  "typ": "JWT"
}

서명이 없으니 누구나 유효한 토큰을 만들 수 있다. 대응은 간단하다. 서버 측에서 허용할 알고리즘을 명시적으로 제한하면 된다.

Jwts.parser()
    .setAllowedClockSkewSeconds(0)
    .setSigningKey(secretKey)
    .parseClaimsJws(token);

• jjwt 같은 현대 라이브러리는 기본적으로 alg: none을 거부한다. 하지만 직접 구현하거나 오래된 라이브러리를 쓸 때는 주의해야 한다.

토큰 탈취 (XSS, 네트워크 스니핑)

토큰은 클라이언트가 보관하고 있으므로, 탈취 위험이 세션보다 높다.

• XSS 방어 — localStorage에 토큰을 저장하면 스크립트로 접근 가능하다. HttpOnly 쿠키를 사용하거나, Content Security Policy(CSP) 헤더를 설정한다
• 네트워크 스니핑 방어 — 반드시 HTTPS를 사용한다. HTTP에서는 Authorization 헤더가 평문으로 전송된다
• 탈취 후 대응 — Access Token 만료 시간을 짧게 유지하고, Refresh Token Rotation을 적용한다

토큰 강제 무효화

JWT는 Stateless이므로 기본적으로 서버에서 강제 무효화할 수 없다. 하지만 실무에서는 계정 정지, 비밀번호 변경 시 강제 로그아웃이 필요한 경우가 있다.

이때 사용하는 게 블랙리스트 방식이다. 무효화할 토큰의 jti(JWT ID)를 Redis에 저장하고, 검증 시 블랙리스트에 있는지 확인한다.

이 방식은 Stateless의 장점을 일부 포기하는 트레이드오프다. 다만 전체 세션을 Redis에서 관리하는 것과 달리, 블랙리스트는 무효화된 소수의 토큰만 저장하므로 부담이 훨씬 적다. 블랙리스트 항목은 해당 토큰의 exp 시간이 지나면 자동으로 삭제하면 된다.

JWT 활용 사례

API 인증 외에도 JWT가 활용되는 곳이 있다.

SSO (Single Sign-On)

인증 서버가 JWT를 발급하면, 여러 서비스가 같은 토큰으로 사용자를 식별한다. 서비스마다 별도의 인증 체계를 구축할 필요가 없고, 한 번 로그인으로 여러 서비스를 이용할 수 있다.

서비스 간 정보 교환

JWT는 서명이 포함되어 있으므로, 위변조가 불가능한 데이터 전달 수단이 된다. 인증 목적이 아니더라도, 서비스 간에 신뢰할 수 있는 데이터를 주고받아야 할 때 활용할 수 있다.

면접 대비