[TIL] 18. 11월 JWT

JSON Web Token

JWT란 무엇인가?

JWT(JSON Web Token)는 사용자 인증 정보를 JSON 형태로 안전하게 전송하기 위한 토큰 기반 인증 방식이다.

쉽게 말해, "이 사람이 누군지"를 증명하는 디지털 신분증이라고 생각하면 된다.

실제 JWT 예시:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

점(.)을 기준으로 구분한 모습이다.

Session vs JWT: 무엇이 다를까?

▪️기존 방식: Session 기반 인증

세션 방식은 서버가 모든 것을 기억하는 방식이다.

1. 사용자가 로그인하면 서버는 세션 저장소(메모리나 DB)에 "유저 A 로그인 함"이라고 기록한다.
2. 그리고 유저에게는 입장권인 Session ID만 준다.
3. 유저가 요청을 보낼 때마다 서버는 저장소를 뒤져서 이 ID가 유효한지 확인해야 한다.

이 방식은 보안성이 좋지만, 치명적인 단점이 있다.

• 서버 부하: 동시 접속자가 10만 명이라면? 서버는 10만 개의 세션 정보를 메모리에 쥐고 있어야 한다.
• 확장성 문제: 서버를 여러 대로 늘릴 경우, A 서버에 로그인한 유저 정보를 B 서버는 모른다. 이를 해결하려면 별도의 세션 서버(Redis 등)를 또 구축해야 한다.

▪️새로운 방식: JWT 기반 인증

JWT는 서버가 기억하지 않는(Stateless) 방식이다.

1. 사용자가 로그인하면 서버는 유저 정보를 담은 토큰(JWT)을 생성해서 유저에게 준다. 서버는 아무것도 저장하지 않는다.
2. 유저는 이 토큰을 가지고 있다가 요청할 때마다 제시한다.
3. 서버는 토큰이 위조되었는지만 검증(Verify)하고 요청을 처리한다.

즉, 서버가 상태를 저장하지 않으므로(Stateless), 서버를 100대로 늘려도 아무런 문제가 없다. 어느 서버에 요청을 보내든 토큰만 검증하면 되기 때문이다.

핵심: 서버는 토큰만 검증하면 됨! 저장할 필요 없음 

---

📊 Session vs JWT 비교표

 

🧩 JWT의 구조

JWT는 점(.)으로 구분된 3개의 부분으로 이루어져 있다:

xxxxx.yyyyy.zzzzz
  ↓     ↓     ↓
Header.Payload.Signature

---

1. Header (헤더)

헤더는 이 토큰은 어떤 종류이고, 어떻게 서명되었는지에 대한 명세서이다.

• alg: 서명 알고리즘 (예: HS256, RSA)
• typ: 토큰의 타입 (JWT)

이것을 Base64Url로 인코딩하면 → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

---

2. Payload (페이로드)

페이로드는 실질적인 데이터(Claims)를 담는 곳이다. 유저의 ID, 이름, 유효기간 등이 여기에 포함된다.

⚠️ 주의사항 Payload는 암호화된 것이 아니라 단순히 Base64Url로 인코딩된 것이다. 그래서 누구나 토큰을 디코딩해서 내용을 볼 수 있다. 따라서 비밀번호나 주민등록번호 같은 민감한 개인정보는 절대 Payload에 담으면 안된다.

---

3. Signature (서명)

역할: 토큰이 위조되지 않았음을 검증

javascript

JWT의 핵심이자 보안을 담당하는 부분이다. 이 토큰이 위조되지 않았음을 어떻게 증명할까?

서명은 Header와 Payload의 내용을 합친 뒤, 서버만 알고 있는 비밀키(Secret Key)를 사용하여 암호화 알고리즘(예: HMAC SHA256)을 돌려서 생성한다.

---

 JWT는 언제 써야 할까?

✅ JWT가 적합한 경우

• RESTful API 서버
• 마이크로서비스 아키텍처
• 모바일 앱 백엔드
• 서버를 여러 대로 확장해야 하는 경우

❌ JWT가 부적합한 경우

• 보안이 극도로 중요한 서비스 (금융 등)
• 실시간으로 권한 변경이 필요한 경우
• 토큰이 너무 자주 갱신되어야 하는 경우