[Web] 1-1 JWT 이론

JWT란 무엇인가?
- 서버가 클라이언트에게 "이 사용자는 누구다"라는 정보를 담아 서명해서 주는 토큰이다.
- 이후 요청마다 서버는 세션 저장 없이 토큰만 검증한다.(Stateless 인증 방식)

 

1. JWT를 왜 쓰는가?

1) 기존 세션 방식

Client -> 로그인
Server -> 세션 생성 + DB/메모리 저장
Client -> JESSIONID 쿠키 전송
Server -> 세션 조회

• 문제
  • 서버 확장 시 세션 공유 필요
  • Redis / Sticky Session 필요
  • 모바일/API 기반 서비스에 불리

2. JWT 방식

Client -> 로그인
Server -> JWT 발급
Client -> Authorizaion 헤더에 JWT 포함
Server -> 서명 검증 -> 만료 확인

• 장점
  • 서버가 상태를 안 가짐(Stateless)
  • MSA / API 서버에 적합
  • 확장성 좋은
• 단점
  • 토큰 탈취 시 위험
  • 강제 로그아웃 어려움

3. JWT 구조 

JWT는 3부분으로 구성됨

Header.Payload.Signature

1) Header

• 어떤 알로리즘으로 서명했는지

{
 "alg": "HS256",
 "typ": "JWT"
}

 

2) Payload(Claims)

{
 "sub": "oss0202",
 "role": "ADMIN",
 "iat": 170000000
 "exp": 170003600
}

• Claim 종류
  • Registerd : sub, iat, exp, iss
  • Custom: userId, role
• 암호화 아님(Base64 인코딩) -> 민감정보 절대 금지

3) Signature

• 위변조 방지 핵심

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secretKey
)

 

4. JWT 인증 흐름(실무 기준)

로그인

1. ID/PW 검증
2. JWT 생성
3. Client에 전달

API 요청

Authorization: Bearer {JWT}

 

서버처리

1. JWT 추출
2. 서명 검증
3. 만료(exp) 체크
4. Claim으로 사용자 인증

5. Access Token / Refresh Tokken 

• 왜 나누는가?
  • Access Token : 짧은 수명(10 ~ 30분)
  • Refresh Token : 긴 수명( 2주 ~ 1달)
• 흐름
  1. 로그인 -> Access + Refresh 발급
  2. Access 만료 -> Refresh로 재발급
  3. Refresh 만료 -> 재로그인
• Refresh Token 저장위치
  • JWT만으로 관리하면 위험하므로 DB or Redis에 저장하는것을 권장

6. JWT 보안 포인트(실부/면접 필수)

• ❌ 하면 안 되는 것
  • Payload에 주민번호, 이메일, 전화번호
  • Access Token을 LocalStorage에만 저장(XSS 취약)
  • 무한 만료 토큰
• ✅ 권장
  • Access Token : 메모리 or Secure Cookie
  • Refresh Token : HttpOnly + Secure Cookie
  • exp, iss, aud 체크
  • 로그아웃 시 Refresh Token 폐기

7. JWT vs Session (면접 요약)

구분JWTSession

구분	JWT	Session
상태	Stateless	Stateful
확장성	좋음	불리
보안	토큰 탈취 리스크	세션 하이재킹
로그아웃	어려움	쉬움
모바일/API	적합	부적합