HTTP는 왜 상태 유지를 따로 해야 할까?

HTTP 프로토콜은 Connectionless하며, Stateless한 특성을 가진다.

즉, 클라이언트가 요청하고 서버가 응답한 뒤에는 연결을 끊고,
서버는 이전 요청에 대한 정보를 기억하지 않는다.

👉 이로 인해 사용자의 상태를 유지해야 하는 기능(로그인, 장바구니 등)을
구현하려면 추가적인 상태 유지 기법이 필요하다.

---

쿠키(Cookie)와 세션(Session)

항목	쿠키 (Cookie)	세션 (Session)
저장 위치	클라이언트 (사용자의 웹 브라우저)	서버 (세션 스토리지, 메모리 등)
용도 예시	- "아이디와 비밀번호를 저장하시겠습니까?" - 쇼핑몰 장바구니 기능 - 팝업 "오늘 더 이상 이 창을 보지 않음" 체크	- 로그인 상태 유지 - 사용자 인증/인가
용량 제한	- 도메인당 20개 - 쿠키 하나당 4KB 제한	- 제한 없음 (단, 서버 자원 사용량 증가 가능)
보안	클라이언트에 저장되므로, 수정·노출 위험 있음	서버에 저장되므로, 상대적으로 안전
사용 흐름	서버가 쿠키 설정 → 브라우저가 저장 후, 요청마다 자동 포함	브라우저는 세션 ID만 저장 (예: JSESSIONID) 실제 데이터는 서버에 저장

---

JWT (Json Web Token)

• 인증에 사용되는 토큰 기반의 인증 방식으로,
  사용자 정보를 토큰 자체에 포함시켜 전달하고 검증하는 방식이다.

• JWT는 총 3개의 부분으로 구성된 문자열이며, .(dot)으로 구분된다.

<Header>.<Payload>.<Signature>

1. Header

토큰 타입 (typ)과 해싱 알고리즘 (alg)을 명시

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

2. Payload (정보)

실제 정보를 담는다.
(ex. 유저 ID, 권한, 닉네임 등)

{
  "sub": "1234567890",
  "name": "tester",
  "role": "admin",
  "exp": 1712345678
}

3. Signature (서명)

Header + Payload + SecretKey를 조합해 암호화한 부분
토큰이 위·변조되지 않았는지 검증하는 역할

---

세션과 JWT는 뭐가 다를까?

• 세션(Session)을 사용하면
  1. 클라이언트가 갖고 있는 정보는 JSESSIONID(발급번호)이다.
  2. 서버는 발급번호를 저장하고 있는 세션 스토리지를 조회해서 인가해준다.
• JWT을 사용하면
  1. 클라이언트가 갖고 있는 정보가 많다. (Base64로 인코딩해서)
  2. 서버는 별문제가 없다고 판단되면 인가해준다.

기존 세션방식의 문제점

이용자 요청에 하나하나 서버가 조회해서 유효한지 체크하고, 인가해줬다.
이용자가 무수히 많다면, 성능저하가 필연적이다!!

반면, JWT는 토큰을 검증(디코딩)만 하면 되므로
추가 조회 없이 빠르게 인가할 수 있어, 상대적으로 빠르다!

---

💡 무조건 JWT를 쓰면 좋겠네!

아니다!
무조건 좋다고 해서 무턱대고 JWT를 사용하면,
몇 가지 보안 이슈에 쉽게 노출될 수 있다.

1. alg: "none" 공격

JWT 헤더의 알고리즘을 alg: "none"으로 바꿔 서버에 보내면,
일부 서버에서는 이 토큰을 정상 토큰처럼 인가해버리는 경우도 있다.

---

2. 복호화가 매우 쉽다.

JWT는 Base64로 인코딩된 문자열이기 때문에,
누구나 쉽게 내용을 복호화(디코딩)할 수 있다.

---

3. 시크릿키 문제

시크릿키를 어느정도 맞추기 쉽기 때문에 조심해야 한다.
키를 매우 길게 적거나, 생성용/검증용 키를 따로 운영하거나 하는 방법을 사용해야 한다.

4. JWT를 탈취하면?

예시) 길 가다가 신용카드를 잃어버렸다..
카드 자체에는 암호가 없어도, 쓰는 사람은 막을 수 없다.

JWT도 마찬가지다.
탈취된 토큰은 유효기간이 끝나기 전까지 계속 사용할 수 있다.

👉 따라서
토큰을 쉽게 탈취당하지 않도록 만들고,
탈취 시 서버 측에서 회수하거나 사용 중지할 수 있는 로직도 필요하다.

❓ 근데 그러면 세션(Session)과 별 차이가 없지 않을까??...

그래서 나온 보완전략이 Refresh Token Rotation이다.

💡 Refresh Token Rotation

Access Token이 만료될 때마다 Refresh Token도 함께 교체를 해주는 것이다.
Refresh Token을 짧게 유지하고, 재사용 불가능하게 만들어 보안을 강화한다.

---

✅ 따라서, 상황에 알맞게 사용하자!

내가 구현하고자 하는 애플리케이션의 특성과 요구사항을 파악해서
알맞은 기술을 사용하면 될 것 같다.

많은 언어를 배우고 돌고돌아 자바/C로 돌아오는 것처럼,
별일 없으면 역사와 전통의 세션(Session) 방식으로 로그인을 구현해보자 ㅎㅎ.

---

출처

JSON Web Token
코딩애플 JWT 대충 쓰면 님들 코딩인생 끝남
내일배움캠프 스프링 숙련 2주차 강의
https://gyoogle.dev/blog/web-knowledge/JWT.html
쿠키와 세션의 개념
https://dev-coco.tistory.com/61