이번 장에서는 프로젝트를 진행하면서 사용했던 스프링 시큐리티 설정들을 정리해보려고 한다. 스프링부트를 공부하면서 가장 낯설게 느껴진 내용이 스프링 시큐리티 부분인거 같다.
아래 코드는 내가 프로젝트를 진행하면서 설정했던 Config 파일이다.
해당 클래스 Bean 주입
스프링 시큐리티 활성(자동설정)
스프링 시큐리티의 자동 설정을 그대로 사용할 수도 있지만 요청, 권한, 기타 설정에 대해서는 필수적으로 최적화한 설정이 들어가야하기 때문에 오버라이드하여 원하는 형식으로 시큐리티를 설정함.
HttpServletRequest 요청 URL에 따라 접근 권한을 설정함 .
요청 URL 경로 패턴을 지정함( 리스트 형식으로도 가능 ).
인증된 유저만 접근이 허용.
그 외 다른 모든 요청들은 인증이나 권한 없이 허용.
스프링 시큐리티의 여러 구성자를 연결하는 데 사용.
스프링 시큐리티에서 기본적으로 제공되는 구글과 페이스북에 대한 OAuth2 인증 방식이 적용.
OAUth2 인증이 성공했다는 URI 설정.
OAuth2 인증이 실패했다는 URI 설정.
응답에 해당하는 헤더를 설정. 설정하지 않으면 디폴트값으로 설정.
XFrameOptionsHeaderWriter의 최적화 설정을 허용하지 않음.( 스프링 시큐리티는 기본적으로 X-Frame-Options Click jacking 공격 막기 설정이 되어 있음) 예제에서는 H2 콘솔(iframe)을 사용하기 때문에 비활성화.
스프링 시큐리티 인증,인가 예외 발생시 처리
인증의 진입 지점. 인증되지 않은 사용자가 허용되지 않은 경로로 리퀘스트를 요청할 경우 '/login'으로 이동.
로그아웃 설정을 진행.
로그아웃이 수행될 URL 지정.
로그아웃이 성공했을 때 포워딩될 URL 지정
로그아웃을 성공 했을 때 삭제될 쿠키값 지정.
설정된 세션의 무효화를 수행하게끔 설정
파라미터 첫번째 인자보다 먼저 시작될 필터를 등록함. (문자 인코딩 필터(filter) 보다 CsrfFilter를 먼저 실행하도록 설정.
CSRF(웹 사이트의 취약점을 이용하여 이용자가 의도하지 않은 요청을 통한 공격) 비활성화. CSRF는 GET을 제외하고 POST, PUT, DELETE시 고의적인 것을 방지하기 위해서 CSRF에 맞는 토큰을 제공해준다. 하지만 모든 REST API에서 토큰이 필요하지 않을 경우가 있을 수 있다.
API 서버와 Web FrontEnd 서버를 나누어서 구성할때 CORS를 설정하는데 이때 스프링 시큐리티를 적용중이라면 이 코드를 작성해줘야한다.
참고자료
처음 배우는 스프링 부트 2