[Spring Security] JWT 인증

JWT(JSON Web Token)

• 토큰 기반 인증
• JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명(Sign)한 메시지를 Web Token으로써 인증 과정에 사용
• 종류
  1. 액세스 토큰(Access Token)
  2. 리프레시 토큰(Refresh Token)
• 구조
  1. Header
  2. Payload
  3. Signature
• 장점
  • Stateless, Scalable(확장 용이) 애플리케이션 구현하기 용이
  • 클라이언트가 request를 전송할 때마다 자격 증명 정보를 전송할 필요가 없다.
  • 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이
  • 권한 부여에 용이
• 단점
  • Payload는 디코딩이 용이 -> Payload에는 민감한 정보를 포함하지 않아야 한다.
  • 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.
  • 토큰은 만료될 때까지 자동으로 삭제되지 않는다. -> 토큰 만료 시간 반드시 추가해야 한다.

Spring Security에서의 JWT 인증 과정

1. 클라이언트가 서버 측에 로그인 인증 요청(Username/Password를 서버 측에 전송)
2. 로그인 인증을 담당하는 Security Filter(Custom Security Filter 생성)가 클라이언트의 로그인 인증 정보 수신
3. Security Filter가 수신한 로그인 인증 정보를 AuthenticationManager에게 전달해 인증 처리를 위임
4. AuthenticationManager가 Custom UserDetailsService(MemberDetailsService)에게 사용자의 UserDetails 조회를 위임
   -> Spring Security의 AuthenticationManager가 대신 처리하므로 신경쓸 필요 없음
5. Custom UserDetailsService(MemberDetailsService)가 사용자의 크리덴셜을 DB에서 조회한 후, AuthenticationManager에게 사용자의 UserDetails를 전달
6. AuthenticationManager가 로그인 인증 정보와 UserDetails의 정보를 비교해 인증 처리
   -> Spring Security의 AuthenticationManager가 대신 처리하므로 신경쓸 필요 없음
7. JWT 생성 후, 클라이언트의 응답으로 전달

자격 검증

JWT를 검증하는 전용 Security Filter를 구현
-> request 당 단 한번만 수행하면 되기 때문에 OncePerRequestFilter 를 확장해서 구현

예외 처리

• JwtVerificationFilter에서 예외 처리는 일반적으로 알고 있는 예외 처리 방식과는 다르게, 단순히 request.setAttribute()를 설정하는 일 밖에 하지 않는다.
• SecurityContext에 클라이언트의 인증 정보(Authentication 객체)가 저장되지 않은 상태로 다음(next) Security Filter 로직을 수행하다보면 결국에는 AuthenticationException 이 발생하게 되고, 이 AuthenticationException은 AuthenticationEntryPoint가 처리하게된다.