refreshToken 저장위치와 형태 고민

RefreshToken의 저장 위치(LocalStorage vs Cookie)

LocalStorage

- 장점: 편리성

- 단점: XSS 취약

 

쿠키 (httpOnly + secure)

- 장점: XSS에 다소 강함(httpOnly + secure)

- 단점:  CSRF에 취약

 

결정

hyper-link(통합플랫폼)에서는 refreshToken을 쿠키에 저장하기로 결정했다. 왜냐하면 httpOnly와 secure 옵션을 주면 XSS에 LocalStorage보다 상대적으로 덜 취약하기 때문이다. 물론 쿠키는 CSRF에 취약하다는 단점이 존재한다. 하지만 우리가 저장하는 것은 refreshToken이다. CSRF 공격이 오더라도, refreshToken만을 가지고는 비지니스 데이터에 영향을 줄 수 없다. 왜냐하면 인증인가에 관련된 책임은 accessToken에, 토큰 재발급은 refreshToken에 책임을 분리하였기 때문이다.

CSRF공격이 오더라도 실제 유저에게 토큰만 재발급 해줄 뿐, 비지니스 데이터에 영향을 줄 수 없기 때문에,

우리는 refreshToken의 위치를 쿠키로 결정했다.

RefreshToken 형태(Jwt  vs 서버관리)

Jwt

- 장점:  statless하다는 토큰방식의 장점

- 단점: 토큰 탈취시 관리에 취약

 

서버관리

- 장점: 토큰 탈취시 관리에 용이

- 단점: 확장에 취약

 

결정

hyper-link(통합 플랫폼)의 서버관리 방식을 선택했다. 서버가 현재 하나이긴 하지만, 이용자가 수가 아직 많지 않기 때문에 토큰 탈취에 좀 더 중점을 둔 선택이었다. 또 서버쪽에서 refreshToken을 redis에 저장하기로 결정했다. refreshToken의 영구적 저장이 불필요하다는 점이 인메모리DB의 특징과 맞아 떨어졌고, 또 redis의 TTL 기능이 토큰 만료 기한을 별도로 관리하지 않아도 된다는 편리성과 맞물리며 결정하게 되었다.