JWT

1. JWT(JSON Web Token)

JSON 형식의 데이터를 서명(Signature)을 통해 위변조를 방지한 토큰으로, 주로 인증(Authentication)과 인가(Authorization)를 위해 사용합니다. JWT를 활용한 인증/인가 매커니즘에서는 세션을 활용한 로그인방식과 달리 서버가 인증상태를 따로 저장할 필요가 없기 때문에 무상태 서버(Stateless)구현이 가능합니다.

---

2. 세션기반 로그인과 JWT기반 로그인

1) 세션기반 로그인

1. 사용자가 아이디와 비밀번호로 로그인 요청을 보냅니다.

2. 서버는 사용자 정보를 확인한 뒤, 세션 ID를 생성하여 서버 메모리에 저장합니다.

3. 클라이언트(브라우저)는 세션 ID를 쿠키(JSESSIONID)에 담아 이후 요청마다 자동으로 전송합니다.

4. 서버는 요청이 올 때마다 세션 저장소를 조회해 사용자를 식별하고 인증을 유지합니다.

• 특징 : 서버가 세션 상태를 직접 관리해야 하므로 서버 확장이 어려워지고, 여러 대 서버를 운영하는 경우 세션 동기화가 필요.

2) JWT 기반 로그인

1. 사용자가 아이디와 비밀번호로 로그인 요청을 보냅니다.

2. 서버는 사용자 정보를 확인한 뒤, JWT 토큰을 생성해 클라이언트에 전달합니다.

3. 클라이언트는 이 토큰을 LocalStorage, 쿠키에 저장합니다.

4. 이후 API 요청 시 클라이언트는 Authorization: Bearer <토큰> 형태로 토큰을 전송합니다.

5. 서버는 토큰의 서명(Signature)과 만료시간(exp)을 검증하고, 유효하다면 요청을 처리합니다.

• 특징: 서버가 별도의 상태를 저장하지 않고 토큰만 검증하므로, 확장성이 뛰어나고 분산 환경에 적합

3. Session기반 로그인과 JWT기반 로그인의 차이점

구분	세션 기반	JWT 기반
인증 정보 저장 위치	서버 메모리/DB	클라이언트 (토큰 보관)
서버 확장성	세션 동기화 필요 → 복잡	Stateless → 확장 용이
보안성	세션 탈취 위험	토큰 탈취 위험 (만료시간/HTTPS 필수)
토큰 크기	가볍다 (세션 ID)	비교적 크다 (Payload 포함)
무효화	서버에서 세션 삭제 가능	별도 블랙리스트/만료 관리 필요

---

4. JWT 구조

JWT는 Header.Payload.Signature 형태로 구성되며, 각 부분은 .으로 구분됩니다.

(1) Header (헤더)

• 토큰 타입(JWT)과 해싱 알고리즘(HS256 등) 정보 저장

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

(2) Payload (페이로드)

• 실제 전송할 데이터(Claims) 저장

• 일반적으로 sub(사용자 ID), exp(만료 시간), role(권한) 등이 포함

{
  "sub": "user123",
  "role": "ADMIN",
  "exp": 1718208000
}

(3) Signature (서명)

• Header + Payload를 비밀키(Secret)로 해싱한 값

• 데이터 위변조 방지

5. JWT 토큰 생성용 의존성

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>