Dev_Henry

+ 내용 추가 프론트에서 카카오 로그인 - 인가코드를 받는 부분까지 처리하고 인가코드를 백엔드에게 넘겨준 후에 나머지 처리하는 로직이 일반적으로 프론트와 백엔드가 분리되어있을 때 사용하는 방식은 맞지만 몇가지 문제가 더있었다. 프론트에서 웹뷰를 사용한다면 이런 로직으로 구현하는데 전혀 문제가 없고 주로 사용하는 방법이다. 그런데 우리 프론트는 flutter를 사용하고 있었고, flutter에서 카카오가 제공해주는 로그인 api를 사용하기 위한 방법은 두가지가 있다. 웹뷰에서 사용할 수 있는 redirect방식 네이티브에서 사용할 수 있도록 기능을 제공하는 sdk 아래에 구현한 내용은 일반적으로 1번 방식에서 가능한 방식이다. 네이티브에서 사용하는 sdk는 인가코드만 달랑 받아와서 따로 서버에 전달할 수 ..

진행중인 프로젝트에서 처음 구현할때 refreshToken도 만들긴 했는데 급하게 만들다 보니 redis 같은 db를 사용한 검증방식도 없었고 어차피 jwt관련 코드가 모두 리팩토링이 필요했기 때문에 refreshToken 부분도 새로 구현하면서 알아보려고 한다. 우선 refreshToken(이하 rtk)은 JWT방식의 단점을 어느정도 보완하고자 생긴 방법인데, accessToken(이하 atk)을 탈취당하면 해커가 계정을 자유롭게 사용할 수 있기 떄문에 atk의 만료시간을 짧게 주고 비교적 만료시간이 긴 rtk을 함께 생성해 둔 뒤에 atk가 만료되었을때 rtk를 통해 atk를 재발급 해주는 방식으로 동작한다.. 라는 내용으로 만들어진 rtk이고 공부를 하면서 찾아본 책, 블로그 등에서도 모두 이정도로..

refreshToken 리팩토링 : https://devsungwon.tistory.com/entry/Spring-JWT-refreshToken%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EB%AF%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0Redis 소셜로그인 리팩토링 : https://devsungwon.tistory.com/entry/Oauth2-%EC%B9%B4%EC%B9%B4%EC%98%A4-%EC%86%8C%EC%85%9C%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81 처음 책을 보고 따라만들어서 jwt토큰 관련 구현이 이상함 문제1. 사용중인 jjwt라이브러리가 옛날 버전이..

작업중인 프로젝트에서 JWT인증방식을 사용하여 로그인을 하도록 만들었다. 대략적인 흐름은 아이디,비밀번호로 로그인을 했을때 스프링 시큐리티에서 login필터를 거쳐서 로그인을 확인하고 성공시 jwt토큰을 발급해준다. 이후 jwt토큰과 함께 요청이 들어오면 토큰체크필터에서 jwt토큰을 검증하는 방식이다. 그런데 책과 자료를 참고하면서 구현하던중 로그인 필터는 AbstractAuthenticationProcessingFilter를 상속받아 구현했지만 토큰체크필터는 OncePerRequestFilter를 이용하는 경우가 많아 필자도 같은 방식으로 구현을 했다. 우선 OncePerRequestFilter에 대해서 찾아보니 모든 서블릿 컨테이너에서 요청 발송 당 단일 실행을 보장하는 것을 목표로하는 필터 기본 클..