로그인 모식도
- login 요청을 받아서 처리하는 과정
- username과 password를 검증하는 과정 -> 8강
- UsernamePasswordAuthenticationFilter, Authentication Manage -> 세션 방식으로 로그인할때는 스프링에서 default로 해줌
- 이번엔 formlogin을 disable 시켜서 구현해야함
스프링 시큐리티 필터 동작 원리
스프링 시큐리티 필터 동작 원리
스프링 시큐리티는 클라이언트의 요청이 여러개의 필터를 거쳐 DispatcherServlet(Controller)으로 향하는 중간 필터에서 요청을 가로챈 후 검증(인증/인가)을 진행한다.
클라이언트 요청 → 서블릿 필터 → 서블릿 (컨트롤러)
- 톰캣의 서블릿 필터를 거쳐서 로그인이 됨
Delegating Filter Proxy
서블릿 컨테이너 (톰캣)에 존재하는 필터 체인에 DelegatingFilter를 등록한 뒤 모든 요청을 가로챈다.
서블릿 필터 체인의 DelegatingFilter → Security 필터 체인 (내부 처리 후) → 서블릿 필터 체인의 DelegatingFilter
- 가로챈 요청은 SecurityFilterChain에서 처리 후 상황에 따른 거부, 리디렉션, 서블릿으로 요청 전달을 진행한다.
- 양측의 필터가 서로 다른 필터임
SecurityFilterChain의 필터 목록과 순서
(모든 필터는 전부 활성화되지 않습니다.)
- form 로그인 disable 시켜서 UsernamePasswordAuthenticationFilter가 동작이 안됨 -> 강제로 커스텀해서 실행
Form 로그인 방식에서 UsernamePasswordAuthenticationFilter
Form 로그인 방식에서는 클라이언트단이 username과 password를 전송한 뒤 Security 필터를 통과하는데 UsernamePasswordAuthentication 필터에서 회원 검증을 진행을 시작한다.
(회원 검증의 경우 UsernamePasswordAuthenticationFilter가 호출한 AuthenticationManager를 통해 진행하며 DB에서 조회한 데이터를 UserDetailsService를 통해 받음)
우리의 JWT 프로젝트는 SecurityConfig에서 formLogin 방식을 disable 했기 때문에 기본적으로 활성화 되어 있는 해당 필터는 동작하지 않는다.
따라서 로그인을 진행하기 위해서 필터를 커스텀하여 등록해야 한다.
로그인 로직 구현 목표
- 아이디, 비밀번호 검증을 위한 커스텀 필터 작성
- DB에 저장되어 있는 회원 정보를 기반으로 검증할 로직 작성
- 로그인 성공시 JWT를 반환할 success 핸들러 생성
- 커스텀 필터 SecurityConfig에 등록
구현
클라이언트 요청 -> 톰캣 진입 -> 일련의 필터들 -> 스프링 서블릿(컨트롤러) 와 같은 방식으로 요청이 이루어집니다.
이때 스프링 시큐리티는 일련의 필터들에서 사용자의 요청을 검증하는데 그 중 저희가 만든 LoginFilter는 UsernamePasswordAuthenticationFilter의 정의에 따라서 /login 경로로 오는 POST 요청을 검증하게 됩니다.
따라서 필터단에서 해당 요청을 캐치하여 검증을 진행하고 응답하기 때문에 컨트롤러에서 처리할 필요가 없습니다.
