#️⃣연관된 이슈

close #173

📝작업 내용

redis refresh token 추가

access token을 key값으로 가지는 refresh 토큰 추가.
refresh 토큰은 access token의 sort 값과 userId 값을 jwt 토큰으로 가집니다.

refresh 토큰은 임의로 1일, access token은 1시간을 유효 기간으로 가집니다.

access 토큰 만료 시 refresh 토큰과 비교 후 새로 발급합니다.

고민점 : 프론트에서 storage에 access 토큰을 저장하는데, access 토큰을 재 발급 받을 경우 어떻게 갱신할 수 있을까?

의견
cookie가 아니라 token을 사용했던 이유: front에서도 제어권을 가져서 개발 시 테스트하기 편하게 하기 위함
-> token을 유지하는 방식이면?

• api 명령 처리 중 재발급이 필요한 경우, 재발급 필요 상태코드를 보내주고 front에서 재발급 api를 다시 요청하기
• api 명령 처리 중 재발급이 필요한 경우, 재발급 및 명령 처리 후 cookie 같은데 같이 보내주고, refresh cookie가 있는 경우 front에서 갱신

문제점 확인

access token을 local storage에 저장하는 현재 방식은 access token 저장 시 http-Only 쿠키를 사용하지 않으면 client가 악성 코드를 활용해 access token 탈취(XSS 공격)가 쉬워짐.
-> 이렇게 access token이 탈취되는 경우, 해당 access token을 키 값으로 하여 refresh 토큰을 사용하는 현재 코드에선 refresh 토큰을 사용하는 보안적 장점이 사라짐.

access token을 키 값으로 사용하지 않고 access token 내부 payload에 사용자 uuid를 저장하여 키 값으로 사용하는 방식을 채용하더라도 access token 탈취 위험이 큰 local storage에 저장하는 방식 사용 시 refresh token에 접근하여 새 access 토큰을 발급 받아 세션 탈취가 가능함.

이를 해결하기 위해선, 아래 두 가지 방안을 생각해봄.

• 추가적인 httponly cookie를 사용하여 sessionId와 같이 client를 식별할 수 있는 키 값을 추가로 저장 후 refresh token의 키 값으로 사용
• access token을 httponly cookie에 저장하여 front 측이 인증 절차에 대한 책임에서 분리

현재 구현 단계에서 시간적인 문제와 refresh token을 사용해야 하는 필요성이 대두되어 해당 PR은 close 함. 이후 리팩토링 과정에서 추가적인 보안 강화 필요.