JWT #1

💙 JWT

JSON Web Token
사용자 인증(Authentication)과 권한 부여(Authorization)에 사용하는 토큰 기반 인증 방식

사용자의 로그인 정보를 안전하게 담아 서버 - 클라이언트 간에 전달하는 서명된 토큰이다.

• 서명된 : 위조되지 않았음을 보장하기 위해 디지털 서명이 포함되어 있다.

💙 구성

세 부분으로 구성된 무자열
xxxxx.yyyyy.zzzzz

부분	내용	설명
Header	토큰 타입과 알고리즘	예: { "alg": "HS256", "typ": "JWT" }
Payload	사용자 정보 (Claims)	예: userId, role, exp(만료시간)
Signature	위조 방지용 서명	비밀 키로 서명하여 위변조 방지

실제 JWT 구조 예시

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiAidXNlcjEiLCAicm9sZSI6ICJVU0VSIiwgImV4cCI6IDE3NTQwMDAwMDB9. XqVfNNjOt-y0IxqFe9fJexBJKrLdKK7-_a9UOi27_xg

• 앞 : Header (alg, typ)
• 중간 : Payload
• 뒤 : Signature (위조 방지용)

💙 Payload

{
  "sub": "user1",
  "role": "USER",
  "exp": 1754000000
}

키	의미	예시 값	설명
sub	Subject (주체)	"user1"	보통 사용자 식별자 (예: user ID, 이메일 등)
role	사용자 권한	"USER"	인증된 사용자의 권한 (예: ADMIN, USER 등)
exp	Expiration (만료 시간)	1754000000	토큰 만료 시간 (Unix timestamp)

실제 JWT 안의 payload

JWT는 base64로 인코딩되기 때문에, 위의 json은
eyJzdWIiOiAidXNlcjEiLCAicm9sZSI6ICJVU0VSIiwgImV4cCI6IDE3NTQwMDAwMDB9
로 변형되어 JWT 중간 부분으로 들어간다.

💙 흐름 (로그인 기반 인증)

1. 사용자 로그인 성공

• 서버가 사용자 정보를 담은 JWT를 발급
• 클라이언트(브라우저/웹)는 이 토큰을 저장 (ex. localStorage, 쿠키)

2. 이후 요청마다

• 클라이언트가 Authorization: Bearer <JWT> 헤더에 토큰을 담아 전송
• 서버는 이 토큰을 검증하여 사용자 인증 처리

3. 서버는 세션을 저장하지 않음

• JWT 자체에 정보가 담겨 있다 (stateless)

stateless(무상태) : 서버가 클라이언트의 이전 요청 상태를 기억하지 않는 구조
stateful(상태 유지 방식) : 서버가 로그인한 사용자의 정보를 메모리에 저장해 놓고 상태를 기억하는 구조

💙 사용 시점

상황	JWT 적합 여부
모바일 앱, SPA(React/Vue) 로그인 처리	적합
서버 간 통신 인증	적합
보안이 민감하고 로그아웃이 자주 필요한 웹사이트	⚠️ 세션 방식이 나을 수 있음

POST /login
→ 응답: JWT 발급

GET /myPage
Authorization: Bearer eyJhbGciOi...

→ 서버는 토큰을 검증하고 로그인된 사용자 정보 사용

💙 OncePerRequestFilter

Spring Framework에서 제공하는 서블릿 필터(Filter) 의 추상 클래스

javax.servlet.Filter 는 한 요청에서 여러 번 실행될 수 있는 위험이 있다.(예:포워딩)
OncePerRequestFilter는 한 요청에 딱 한 번만 doFilterInternal() 메소드가 실행되도록 보장한다.

즉, 중복 실행을 방지하면서 필터 기능을 구현할 수 있도록 도와주는 클래스

사용위치

보통 Spring Security에서 인증/인가 처리를 위한 JWT 필터, 로깅 필터 등에 사용한다.

흐름도

[요청] → [OncePerRequestFilter 구현체 (예: JwtFilter)] → [다음 필터 or 컨트롤러]

💙 FilterChain

자바 웹 애플리케이션에서 여러 개의 필터를 순차적으로 연결하여 실행할 수 있도록 해주는 객체이다.

보통 doFilter() 메소드 안에서 다음 필터 또는 서블릿으로 요청을 넘길 때 사용한다. (예: Spring Security, Logging Filter, JWT Filter 등)

예시 상황

• 인증 필터 : JWT가 유효한지 검사 후 chain.doFilter() 호출
• 로깅 필터 : 요청 전호우의 로그를 남김
• CORS 필터 : 헤더 설정 후 다음 필터로 넘김

필터 체인을 넘기지 않으면 요청이 중단되고, 컨트롤러에 도달하지 않게 된다.

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {

    // 전처리 로직
    // 현재 요청 URI 로그 출력. 디버깅용
    System.out.println("🔥 JwtFilter 진입 : " + request.getRequestURI());

    // 다음 필터로 전달 (여기서 안 넘기면 필터 체인이 끊김)
    chain.doFilter(request, response);

    // 후처리 로직
    System.out.println("필터 종료");
}

흐름 구조

[요청]
  ↓
Filter1 → Filter2 → Filter3 → Controller
  ↑                        ↑
후처리                   후처리

🤍 회고

2차 프로젝트를 진행하면서 JWT(Json Web Token)를 사용하게 되었고, 이를 보다 정확히 이해하기 위해 관련 개념과 동작 방식을 깊이 있게 학습하였다.

stateless 와 stateful 에 대해 살짝 봤는데 매번 데이터를 주고 받는게 더 좋나? 싶은 생각이 들었다. GPT에 질문해보았고 아래와 같이 답을 받았다.

JWT를 매번 주고 받는 것, 괜찮을까??

장점 : 서버 부담이 적다 (Stateless 구조)

• 서버가 상태(session)를 기억하지 않아도 되므로 확장성이 좋다
• 서버 재시작/로드밸런싱해도 별도 세션 복제 불필요
• 사용자 수가 많을수록 메모리 부담 줄어듦

단점 : 매번 정보가 전달되니 크기/보안 주의

문제	설명
🔹 네트워크 비용	JWT는 보통 1~2KB 크기 → 요청이 많아지면 네트워크 낭비 우려
🔹 보안 이슈	토큰 안에 인코딩된 사용자 정보가 담겨 있음 → 탈취 시 위험 (암호화 X, 서명만 함)
🔹 무효화 어려움	한 번 발급한 토큰은 유효시간 동안 취소가 어려움 (서버가 상태를 모르기 때문)

일반적으로는?

상황	권장 방식
분산 서버 / 확장성 중요	JWT (stateless) 유리
보안, 토큰 취소 필요	세션 기반 (stateful) 또는 리프레시 토큰 병행 권장

즉, 정리하자면
JWT를 매번 주고받는 것은 확장성과 유지보수 측면에서 장점이 있지만,
보안과 성능 측면에서는 설계에 주의가 필요하다.
그래서 JWT + Refresh Token 조합이 자주 쓰인다.