[#3][다시, 처음부터 #6]JWT를 활용한 실전 적용과 필터 기반 인증 흐름

1. 개념 설명 (Concept)

 

6일차 핵심 주제는 Spring Security와 JWT를 연결해서 실제 요청 흐름에 적용하는 것이에요.
단순히 JWT 구조를 아는 것에서 멈추지 않고, 서버가 어떻게 요청(Request)마다 토큰을 해석하고 권한을 적용하는지를 다룹니다.

실제 서비스 흐름:

1. 클라이언트(브라우저/앱) → 로그인 요청 → 서버에서 JWT 발급 (Access Token, 필요시 Refresh Token 포함)
2. 이후 클라이언트는 모든 요청의 HTTP Header(Authorization: Bearer <토큰>)에 JWT를 넣어 보냄
3. 서버(Spring Security 필터 체인)는 JwtAuthenticationFilter 같은 커스텀 필터에서 토큰을 해석
   • 토큰 유효성 검증 (서명 확인, 만료 시간 확인)
   • 토큰 안에 담긴 사용자 정보(Claims) 추출
   • 인증 객체(SecurityContextHolder)에 저장 → 이후 컨트롤러 단에서 @AuthenticationPrincipal 같은 방식으로 접근 가능
4. 권한(Role)에 따라 접근 가능 여부 결정

즉, 6일차는 JWT를 서버의 필터(Interceptor 레벨보다 앞단)에서 처리하는 구조를 배우는 단계예요.

 

---

2. 올바른 용어 (Terminology)

 

• Filter (필터): Spring Security에서 요청/응답을 가로채서 인증·인가를 수행하는 컴포넌트.
• Authentication (인증): 사용자가 누구인지 확인하는 절차 (e.g., JWT 검증).
• Authorization (인가): 사용자가 해당 자원(Resource)에 접근 가능한지 확인하는 절차 (e.g., ROLE_USER, ROLE_ADMIN).
• SecurityContext (보안 컨텍스트): 현재 인증된 사용자 정보(Authentication 객체)를 담아두는 저장소.
• Bearer Token (베어러 토큰): Authorization 헤더에 담는 표준 방식 "Bearer <token>".

 

---

3. 잘못 쓰기 쉬운 표현 + 실제 맥락 (Misuse & Context)

 

• ❌ 잘못된 표현:
  • "JWT는 DB를 안 써서 인증이 필요 없다" → 틀림.
    → JWT는 "상태 저장을 DB에 두지 않는다"는 뜻이지, 인증 자체가 필요 없다는 뜻이 아님.
  • "JWT는 자동으로 Spring Security에서 검증된다" → 틀림.
    → 기본 Spring Security는 세션 기반이므로, JWT를 쓰려면 커스텀 필터를 직접 추가해야 함.
• ✅ 현업에서 쓰는 표현:
  • "우리는 세션 대신 JWT 기반 인증을 적용했어요. 그래서 JwtAuthenticationFilter를 필터 체인에 등록해서 모든 요청을 검사합니다."
  • "Authorization 헤더에서 Bearer 토큰을 꺼내 검증하고, SecurityContextHolder에 Authentication 객체를 저장합니다."

---

4. 면접 예시 (Interview Q&A)

 

Q1. Spring Security에서 JWT 인증은 어떻게 동작하나요?

• A: 클라이언트가 Authorization 헤더에 담아 보낸 JWT를 커스텀 필터에서 꺼내고, 시그니처와 만료 여부를 검증합니다. 이후 Claims 안의 사용자 정보를 Authentication 객체로 변환해 SecurityContextHolder에 저장합니다. 이렇게 하면 컨트롤러 단에서 인증된 사용자 정보에 접근할 수 있습니다.

Q2. 세션 기반 인증과 JWT 기반 인증의 차이는 무엇인가요?

• A: 세션 기반은 서버 메모리/DB에 세션 상태를 저장하는 반면, JWT는 상태 정보를 토큰 자체에 담아 클라이언트가 보관합니다. 따라서 서버 확장성(Stateless 아키텍처)에 유리하지만, 토큰이 유출되면 만료 전까지 차단이 어렵다는 단점이 있습니다.