IT/디버깅

jwt 사용 시 remember me 적용 안되는 이슈

happy_life 2024. 1. 25. 14:44

spring version 3.xx 와 jwt를 사용해 login을 구현한 프로젝트에서 remember me 로 로그인 유지를 구현하려고 하는 중 remember me cookie가 생성되지 않아 이를 해결하는 과정을 포스팅합니다.

 

 

1. RememberMe가 동작하지 않는지 체크

spring security의 rememberMeAuthenicationFilter는 잘 동작하고 있음을 확인했습니다.

remember Me AuthenticationFilter가 Spring Security에서 동작함

 

 

 

2. 다른 원인에 대한 고민 - Session Cookie

SecurityConfig의 SessionCreationPoilicy.STATELESS 사용은 Session을 생성하지 않음을 확인하였고, 쿠키 기반인 remember-me 세션 쿠키가 생성되지 않는 것이 당연한 것이었습니다.  

따라서 Security의 remember-me를 사용해 로그인을 유지하는 것이 아니라, jwt token을 만들 때를 분기처리 하여 로그인 유지 체크시 jwt token의 유효기간을 연장하는 방식으로 구현하도록 하기로 하였습니다.

 

따라서

1. 먼저 필요없는 SecurityConfig의 remember me 코드를 삭제하였습니다.

SecurityConfig의 rememberMe 관련 코드 삭제

 

'

 

2. 로그인 dto에 rememberMe boolean type을 추가하고, jwtProvider의 gererateToken 부분을 분기 처리 해주었습니다.

dto에 boolean 추가/ 분기처리

 

 

 

3. 보안에 대한 고민

jwt token을 늘리면 보안에 문제가 생길 것같다는 판단을 하였습니다. 이와 관련해 검색하던 중 여러 가지 방법들을 알아보게 되었습니다.

 

1. ios의 keyChain같은 secure storage 방식을 사용하기 ( 저희 프로젝트는 ios에 연동하는 프로젝트입니다.)

2. https 사용하기

3. access token을 길게 하기보단, access token을 짧게 하고 refresh token을 길게 하기

 

 

 

4. refresh token을 길게 하고 access token을 짧게하는 것은 access token을 길게하는 것에 비해 어떤 보안적 장점이 있는지에 대한 고민

1. access token이 탈취된다고 하더라도, 짧은 만료기간이라면 만료된 이후 접근할 수 없습니다.

 

2. access token은 stateless 상태 시스템에서 일반적으로 취소할 수 없지만, refresh token은 취소할 수 있습니다. 보안 위반이 의심되는 경우 refresh 토큰을 취소하고 새로운 access token의 발급을 방지할 수 있습니다.

 

3. refresh token은 access token을 갱신해야 할 때만 전송되는 토큰입니다. 따라서 액세스 토큰의 사용보다 빈도가 낮고 네트워크를 통해 전송되는 횟수가 줄어들어 intercept의 위험이 적어집니다. 

Q) access token을 짧게 하면 refresh token의 전송 빈도수가 높아질텐데 왜 이런건지?

-> access token은 매 api 요청마다 전송되므로 refresh 토큰에 비해 당연히 빈도수가 더 높습니다. 정확히는 access token의 만료기간이 짧아지므로 api 요청마다 전송되는 access token의 횟수는 동일하겠지만, access token 탈취된다고 하더라도  1번 이유에 의해 오래 사용이 불가능하며, refresh token 의 생성 빈도수가 높아진다고 하더라도 2번의 경우로 취소할 수 있기 때문에 보안적으로 더 안전합니다. 따라서 3번은 정확한 답변은 아닙니다.