서버 측 주도권단순하게 JWT를 발급하여 클라이언트 측으로 전송하면 인증 / 인가 에 대한 주도권 자체가 클라이언트 측에 맡겨진다. JWT를 탈취하여 서버 측으로 접근할 경우 JWT가 만료되기 까지 서버 측에서는 그것을 막을 수 없으며, 프론트 측에서 토큰을 삭제하는 로그아웃을 구현해도 이미 복제가 되었다면 피해를 입을 수 있다. 이런 문제를 해결하기 위해 생명주기가 긴 Refresh 토큰은 발급 시 서버 측 저장소에 기억한 후 기억되어 있는 Refresh 토큰만 사용할 수 있도록 서버 측에서 주도권을 가질 수 있다.구현 방법발급 시Refresh 토큰을 서버 측 저장소에 저장갱신 시 (Refresh Rotate)기존 Refresh 토큰을 삭제하고 새로 발급한 Refresh 토큰을 저장토큰 저장소 구현토큰..

Refresh Rotate란Reissue 엔드포인트에서 Refresh 토큰을 받아 Access 토큰 갱신 시 Refresh 토큰도 함께 갱신하는 방법이다. 장점Refresh 토큰 교체로 보안성 강화로그인 지속시간 길어짐추가 구현 작업발급했던 Refresh 토큰을 모두 기억한 뒤, Rotate 이전의 Refresh 토큰은 사용하지 못하도록 해야 함.Reissue기존 ReissueController 코드에서 일부 로직만 추가하면 된다. PostMapping("/reissue") 경로 메소드@PostMapping("/reissue")public ResponseEntity reissue(HttpServletRequest request, HttpServletResponse response) { //get r..

요청 로직 서버 측 JWTFilter에서 Access 토큰의 만료로 인한 특정한 상태 코드가 응답되면 프론트 측 Axios Interceptor와 같은 예외 핸들러에서 Access 토큰 재발급을 위한 Refresh을 서버 측으로 전송한다.reissue@Controller@ResponseBodypublic class ReissueController { private final JWTUtil jwtUtil; public ReissueController(JWTUtil jwtUtil) { this.jwtUtil = jwtUtil; } @PostMapping("/reissue") public ResponseEntity reissue(HttpServletRequest requ..

프론트에서 데이터 요청프론트의 API Client로 서버측에 요청을 보낸 후 데이터를 획득한다. 이때 권한이 필요한 경우 Access 토큰을 요청 헤더에 첨부하는데 Access 토큰 검증은 서버 측 JWTFilter에 의해 진행된다.JWTFilter// 헤더에서 access키에 담긴 토큰을 꺼냄String accessToken = request.getHeader("access");// 토큰이 없다면 다음 필터로 넘김if (accessToken == null) { filterChain.doFilter(request, response); return;}// 토큰 만료 여부 확인, 만료시 다음 필터로 넘기지 않음try { jwtUtil.isExpired(accessToken);} catch (..

로그인 성공 시 다중 토큰 발급과 발급 위치로그인이 성공하면 기존에 단일 토큰만 발급해지만 Access/Refresh 에 해당하는 다중 토큰을 발급해야 한다. 따라서 로그인이 성공한 이후 실행되는 successfulAuthentication() 메소드 또는 AuthenticationSuccessHandler를 구현한 클래스에서 2개의 토큰을 발급한다. 각각의 토큰은 생명주기와 사용처가 다르기 때문에 심화 2에서와 같이 서로 다른 저장소에 발급한다.Access : 헤더에 발급 후 프론트에서 로컬 스토리지 저장Refresh : 쿠키에 발급로그인 성공 핸들러성공 루틴@Overrideprotected void successfulAuthentication(HttpServletRequest request, Http..

프로젝트 파일이전에 진행했던 프로젝트기반 코드에서 변경될 부분로그인 성공 핸들러JWT 검증 필터

1. 토큰 사용 추적"Spring Security JWT" 시리즈를 통해 구현한 단일 토큰의 사용처를 추적하면 아래와 같다. 로그인 성공 JWT 발급 : 서버 측 -> 클라이언트로 JWT 발급권한이 필요한 모든 요청 : 클라이언트 -> 서버 측 JWT 전송 권한이 필요한 요청은 서비스에서 많이 발생한다. (회원 CRUD, 게시글/댓글 CRUD, 주문 서비스, 등등)따라서 JWT는 매시간 수많은 요청을 위해 클라이언트의 JS  코드로 HTTP 통신을 통해 서버로 전달된다. 해커는 클라이언트 측에서 XSS를 이용하거나 HTTP 통신을 가로채서 토큰을 훔칠 수 있기 때문에 여러 기술을 도입하여 탈취를 방지하고 탈취되었을 경우 대비 로직이 존재한다.2. 다중 토큰 : Refresh 토큰과 생명주기위와 같은 문제..

실습 목표스프링 시큐리티 단일  JWT 발급을 넘어 보안을 위한 여러가지 심화적인 구현 방법을 알아본다.

자료CORS | 스프링 시큐리티 공식 자료 바로가기 CORS :: Spring SecuritySpring Framework provides first class support for CORS. CORS must be processed before Spring Security, because the pre-flight request does not contain any cookies (that is, the JSESSIONID). If the request does not contain any cookies and Spring Security isdocs.spring.io CORS란교차 출처 리소스 공유 위키피디아 바로가기 교차 출처 리소스 공유 - 위키백과, 우리 모두의 백과사전위키백과, 우리 모두의 백..

JWTFilter를 통과한 뒤 세션 확인@Controller@ResponseBodypublic class MainController { @GetMapping("/") public String mainP() { String name = SecurityContextHolder.getContext().getAuthentication().getName(); return "Main Controller : "+name; }}세션 현재 사용자 아이디SecurityContextHolder.getContext().getAuthentication().getName();세션 현재 사용자 roleAuthentication authentication = SecurityContextHol..