애송이의 유산

jwt 토큰을 통해 로그인을 구현하면 세션에 비해 서버에 부담이 적고, 확장하기도 편리하다는 장점이 있다. 하지만 온전히 사용자가 보내는 http 메시지에 담긴 토큰을 기반으로 서버가 유저를 판단하기 때문에, 이 토큰이 탈취당하면 탈취자를 사용자로 오인하게 되어 매우 위험하다. 프로젝트에서 이를 극복하기 위해 refresh 토큰을 도입했다. Refresh Token 이란? 이전에 작성한 jwt토큰을 이용한 로그인 방식은 엄밀히 보면 access를 위한 토큰이라 볼 수 있다. 그래서 사람들은 보통 이 토큰을 access token이라 지정하는 경우도 많다. 문제는 이 토큰이 탈취당하면 리스크가 크다는 점인데, 이는 access 토큰의 유효시간을 짧게 설정해서 보완할 수 있다. 유효시간이 짧다면 공격하는 사..

이전 과정을 거쳤다면 다음으로 accessDeniedHandler와 authenticationEntryPoint를 커스터마이징하는 것이다. 기본적으로 제공되지만 인증, 인가가 실패했을 때 서버와 클라이언트에서 더 명확하게 판단할 필요가 있었기에 직접 작성해야했다. 먼저 CustomAccessDeniedHandler이다. CustomAccessDeniedHandler.java @Component public class CustomAccessDeniedHandler implements AccessDeniedHandler { private final Logger log = LoggerFactory.getLogger(CustomAccessDeniedHandler.class); @Override public vo..

프로젝트를 하면서, 로그인을 구현해야하는 단계에 왔을 때, sns로그인을 이용해 간단하게 넘길지 아니면 직접 구현할지 팀원과 의논했다. spring security는 강의에서도 생각보다 자세하게 다루지 않아, 깊게 공부하려면 아예 따로 spring security강의를 찾거나 레퍼런스를 뒤지면서 처음부터 공부해야했다. 그래도 이왕 하는 김에, 처음부터 머리박으면서 구현해보는게 좋겠다는 생각으로 뛰어들었다. 로그인을 구현할 때, 먼저 세션과 토큰 방식 중 선택해야했다. 두 방식의 차이점은 크게 보면 세션은 유저 정보가 서버에 저장되고, 토큰은 유저 정보를 클라이언트에서 보낸다는 점이다. 우리는 토큰 방식을 선택했는데, 이는 다음과 같은 이유에서 였다. 1. 세션같은 경우, 유저 정보를 서버가 저장한다. 유..