Spring47

• 

  Refresh 토큰 서버측 저장 단순하게 JWT를 발급하여 클라이언트측으로 전송하면, 인증/인가에 대한 주도권 자체가 클라이언트 측에 맡겨진다.JWT를 탈취하여 서버측으로 접근하면 JWT가 만료되기 까지 서버측에서는 그것을 막을 수 없으며, 프론트 측에서 토큰을 삭제하는 로그아웃을 구현해도 이미 복제가 되었다면 막을 방법이 없다.이런 문제를 해결하기 위해서 생명 주기가 긴 Refresh 토큰을 발급하는 경우에서는 서버 측에서 이를 저장하고 저장된 Refresh 토큰의 유효한 경우에만 사용할 수 있도록 주도권을 가져야한다.구현 방법Refresh 토큰을 서버측 저장소에 저장( Redis , mysql 등 )기존 Refresh 토큰을 삭제하고 새로 발급한 Refresh 토큰을 저장토큰 저장소 구현RDB 또는 Redis와 같은 데이터베이스를 .. Spring/시큐리티 2024. 6. 23.

• 

  Refresh 토큰 Rotate Refresh 토큰을 받아 Access 토큰 갱신 시 Refresh 토큰도 함께 갱신 되는 방법을 Refresh Rotate라고 부른다.장점Refresh 토큰 교체로 보안성 강화로그인 지속시간 길어짐추가 구현 작업발급했던 Refresh 토큰을 모두 기억한 뒤, Rotate 이저느이 Refresh 토큰을 사용하지 못하도록 해야한다.why? ) 이미 사용된 토큰으로 다시 Access Token을 요청하는 Replay Attack 상황으로부터 앱을 보호하는 것이다.발신자를 제약하는 조건(Refresh Token 블랙리스트)없이는 Replay Attack 상황에서 서버가 액터가 정당하거나 악의적임을 아는 것이 불가능하다. 이전에 사용된(무효화 된) Refresh Token이 인증 서버로 전송되면 가장 최근 발행.. Spring/시큐리티 2024. 6. 23.

• 

  Refresh 토큰으로 Access 토큰 재발급 Access Token의 만료 기간이 지난 후에는 Refresh Token을 활용해서 다시 Access Token을 발급해준다. 그리고 이는 위와 같은 모식도를 따른다.( 1 )서버에서 Access Token이 만료된 경우 특정 응답을 보내주고,( 2)프론트에서는 Axios Interceptor와 같은 예외 핸들러로 Access 토큰 재발급을 위한 Refresh Token을 서버측으로 전송한다.( 3 )그리고 이를 받은 서버에서는 Refresh 토큰을 받아서 새로운 Access 토큰을 응답한다. 먼저, RefreshToken 처리를 위한 Controller를 만들어준다. 그리고 Refresh Token 처리를 위한 로직을 서비스에서 만든다. 마지막으로 Config에서 해당 로직에 대한 접근을 permiA.. Spring/시큐리티 2024. 6. 23.

• 

  Access 토큰 필터(JWTfIlter) 로그인에 따른 JWT 발급과 서비스 사용에 따른 토큰 사용의 흐름을 이해하자면 위와 같다. 클라이언트의 로그인 요청에 따라서 서버는 JWT를 발급하고 이후 지급된 Access 토큰을 가지고 서비스를 사용할 때마다 서버에 토큰을 던지는데 서버는 JWTFilter를 통해 이를 검증한다. ( 만료 및 위조나 권한 등 ) 따라서 JWTFilter를 구현한 코드를 보자 OncePerRequestFilter를 상속받은 후에 doFilterInternal에서 클라이언트로 받은 request를 처리한다. 먼저 앞서 서버에서 “access”로 헤더에 담아 토큰을 발급했다. 따라서 토큰의 헤더에 “access”로 담긴 토큰을 가져오고 이것이 존재하는 지, 만료되었는지 확인하는 것이다. 여기서 중요한 점은 해당 로직에서 (.. Spring/시큐리티 2024. 6. 23.

• 

  다중 토큰 발급(refresh/access) 로그인이 성공하면, 단일 토큰이 아닌 (refresh/access)에 해당하는 다중 토큰을 발급해보겠다. 따라서 로그인이 성공한 이후 실행되는 successfulAuthentication() 메소드 또는 AuthenticationSuccessHandler를 구현한 클래스에서 2개의 토큰을 발급한다. 각 토큰은 생명주기와 사용처가 다르기에 서로 다른 저장소에 발급한다.access토큰 헤더에 발급 후 프론트에서 로컬 스토리지에 저장refresh토큰 쿠키에 발급이제 다중 토큰 발급을 위한 로직을 구현해보자.먼저 UsernamePasswordAuthenticationFilter를 implement한 필터에서 로그인 성공 핸들러인 successfulAuthentication 핸들러에서 로그인 성공에 따른 토큰 발.. Spring/시큐리티 2024. 6. 23.

• 

  보안을 위한 JWT JWT 토큰을 사용하는 경우는 크게 아래와 같을 것이다. 로그인 성공 시 JWT 발급 → 클라이언트로 JWT 발급권한이 필요한 모든 요청에 대해 클라이언트 → 서버측으로 JWT 전송 이러한 흐름에 따라서 JWT 를 주고받는 요청들은 다음과 같은 고려사항이 있을 수 있다.(권한이 필요한 경우, 회원 CRUD / 게시글 및 댓글 CRUD / 주문 서비스 등등의 서비스 단에서 발생하는 많은 요청 및 로직) 따라서 서버가 클라이언트로 발급한 이후에 JWT는 매시간 수많은 요청에 있어 클라이언트가 서버에 전달한다.하지만, 이런 경우 해커는 클라이언트 측에서 XSS를 이용한다거나 HTTP 통신을 가로채서 토큰을 훔칠 수도 있기에 여러 기술을 도입하여 이를 방지하고 대비책이 필요하고 존재한다.그 방법에는 다음과 같은.. Spring/시큐리티 2024. 6. 23.

• 

  시큐리티 기본 원리( 5 ) - SecurityContextHolder( 인증 정보 공유 방식 ) SecurityFilterChain 내부에 존재하는 많은 필터로 시큐리티 관련 작업을 진행한다.모든 작업은 필터마다 기능 단위로 분업하여 진행하기에 앞에서의 작업이 이후 필터가 알기 위한 저장소 개념이 필요하다. 단편적인 예시로 인가 필터가 작업을 하려면 유저의 role 정보가 필요하게 되는데,앞단의 필터에서 유저에게 role값을 부여한 결과를 인가 필터에 도달하기 까지 공유해야 확인할 수 있다. 시큐리티의 정보 공유 방식  즉, 인가 필터 이전에 아이디, 로그인 여부, role 데이터 등의 정보를 저장하고 있을 곳이 필요한데,이러한 정보는 ‘Authentication 객체’가 저장한다  Authentication 객체가 담고 있는 정보는 크게 아래와 같다. Principal : 유저에 대한 정보Cred.. Spring/시큐리티 기본원리 2024. 6. 15.

• 

  시큐리티 기본 원리( 4 ) - SecurityFilterChain 구조 지난 포스팅에서 SecurityFilterChain을 등록하고 다중 필터에서 적절하게 맵핑하여 활성화하는 방법에 대해 알아보았다.이번에는 SecurityFilterChain의 구조에 대해서 다뤄보겠다. SecurityFilterChain의 내부 구조하나의 SecurityFilterChain 내부에는 N개의 필터가 있어 각각의 필터가 하나의 로직을 수행하는 시작점으로 작용한다.여기서 시작점으로 작용한다는 의미는 실제 필터는 특정 기능을 수행하도록 만드는 역할만 담당할 뿐,실제 기능의 구현은 스프링 컨테이너 내부에 담긴 Bean이 담당한다.  즉, 각 필터에 따라 스프링 컨테이너 내부의 구현체에 의하여 기능을 제공하는 것이다.  SecurityFilterChain에 등록된 필터SecurityFilterCha.. Spring/시큐리티 기본원리 2024. 6. 15.

• 

  시큐리티 기본 원리( 3 ) - SecurityFilterChain( 다중 필터 경로 매핑 ) 앞서 시큐리티의 전체적인 흐름을 살펴본 내용에 의하면, DelegatingFilterProxy를 이용해서 요청을 가로채고 FilterChainProxy 에 도달하면 각 SecurityFilterChain의 시큐리티 로직을 통해서 필요한 인증 인가 기능을 구현하게된다. 그리고 SecurityFilterChain의 부분이 실제 우리가 시큐리티에서 필요한 로직과 기능을 구현하는 부분이다.  커스텀 SecurityFilterChain 등록법먼저, 스프링 시큐리티 의존성을 추가하면 기본적인 DefaultSecurityFilterChain 하나가 등록된다. 이후에 우리가 SecurityFilterChain 을 등록하면 DefaultSecurityFilterChain 이 사라지고 커스텀 마이징한 SecurityFil.. Spring/시큐리티 기본원리 2024. 6. 15.

• 

  시큐리티 기본 원리( 2 ) - DelegatingFilterProxy / FilterChainProxy 시큐리티의 동작 원리에 큰 구성으로는 DelegatingFilterProxy / FilterChainProxy / SecurityFilterChain이 있다.그 중 DelegatingFilterProxy와 FilterChainProxy이 무엇인지 살펴보자.  DelegatingFilterProxy / FilterChainProxy 이란?DelegatingFilterProxy 먼저 DelegatingFilterProxy는 스프링에 시큐리티 의존성이 활성화되어 있다면, 클라이언트의 요청을 가로채어서 등록된 FilterChainProxy로 요청을 보내는 역할을 수행하며, 특정한 시큐리티의 로직을 수행하지는 않는다.  그리고 DelegationgFilterProxy에 FilterChainProxy Bean으로 .. Spring/시큐리티 기본원리 2024. 6. 15.

• 

  시큐리티 기본 원리( 1 ) - 내부구조 및 동작원리 스프링과 요청 처리의 구조 클라이언트와 스프링 서버의 관계는 위와 같은 그림으로 나타낼 수 있다. 클라이언트의 요청에 따라 Was 컨테이너를 거쳐 스프링 컨테이너로 가서 요청에 따른 컨트롤러에 도달한다. 시큐리티를 학습함에 있어 위의 도식에서 살펴볼 것은 ‘Filter’이다.그 이유는 Filter를 사용하여 클라이언트의 요청을 가로채고 시큐리티 역할과 로직을 수행하도록 구현되기 때문이다. 클라이언트의 요청에 따른 시큐리티 동작 과정 WAS의 필터에 하나의 필터를 만들어서 넣고 해당 필터에서 요청을 가로챈다.해당 요청은 스프링 컨테이너 내부에 구현되어 있는 스프링 시큐리티 감시 로직을 거친다.시큐리티 로직을 마친 후에 WAS의 다음 필터로 복귀한다. 또한 스프링에서 시큐리티 로직 또한 여러개의 필터들이 나.. Spring/시큐리티 기본원리 2024. 6. 15.