Access Token과 Refresh Token의 위치

문제 상황

항상 헷갈리던 녀석이다.
쿠키에 저장하는 방법이 있고 세션이나 로컬 스토리지에 저자하는 방법이 있다. 항상 해오던 방식은 쿠키에 저장하던 방식이었기 때문에 쿠키에 지속적으로 저장은 해왔지만 Access Token과 Refresh Token은 다른 곳에 저장을 해야한다는 생각은 해왔기 때문에 찾아보다가 드디어 답을 내렸다.

문제 해결1

우선, 세션이나 로컬 스토리지에 저장을 하게 된다면 자바스크립트를 통해 접근을 하여 저장을 하게 된다. 이렇게 된다면 자바스크립트를 이용하여 접근을 했기 때문에 XSS 공격에 취약해진다.

React를 사용한다면 아래와 같은 특성으로 인해 XSS 공격에 대비를 할 수 있다고 한다.

> React DOM은 JSX에 삽입된 모든 값을 렌더링하기 전에 이스케이프한다.

따라서, 세션이나 로컬 스토리지에 더욱 중요한 것을 저장하는 게 맞지 않나 싶다.
물론, 백에서도 XSS 공격을 대비한다면 더 좋을 것 같다.

그 다음으로 쿠키에 저장하는 방법이 있다. 쿠키 역시 자바스크립트로 접근이 가능하므로 HTTP Only 옵션을 걸어줘야한다.

HTTPS가 적용되지 않은 이미지 등으로 인한 쿠키 탈취가 이뤄질 수 있으므로 ```secure``` 옵션도 걸어주어야 한다.

하지만 이렇게 쿠키에 담게 된다면 XSS 공격은 당하지 않더라도 CSRF 공격에 당할 위험이 존재한다.

CSRF 공격은 토큰 값 자체를 가져오기보다 로그인 된 상태로 특정 위험한 동작을 하게 만든다고 한다. 물론 어찌저찌 토큰 값도 들고올 수 있다고 한다.

위의 특성들을 토대로 생각해보았을 때 Access Token을 XSS 공격에 대비한채로 세션이나 로컬 스토리지에 보관하고 Refresh Token을 쿠키에 담아 관리하는 것이 좋다고 생각했다.

문제 해결1 - 1

만약 Refresh Token의 저장 방식이 걱정된다면 여기서 RTR(Refresh Token Rotation) 방식을 사용해 볼 수도 있겠다.

이 방법은 Refresh Token을 통해 Access Token을 재발급 할 때 Refresh Token을 새 것으로 교체해서 단 한번만 사용할 수 있도록 하는 방식이다.

> 여기에 이미 사용된 Refresh Token으로 요청이 들어오면 모든 Refresh Token을 폐기하는 보안 조치도 추가로 넣어준다고 하네요.

물론 이렇게 하더라도 사용하지 않은 Refresh Token을 탈취하면 한 번은 Access Token을 발급받을 수 있지만, 탈취된 Refresh Token이 무한정 사용되는 것은 막을 수 있습니다.

만약 Access Token의 저장 방식이 걱정된다면 여기서 자바스크립트 내에서 private 변수를 활용하는 방식을 사용해 볼 수도 있겠다.

React를 사용하고 있고, 리액트는 SPA(Single Page Application)이므로, 페이지를 이동하는 것처럼 보여도 페이지가 실제로 이동하는 것이 아니기 때문에 private 변수가 그대로 유지된다.

> 단, 새로고침을 하면 변수가 날아갑니다. 때문에 이 경우에 추가로 Refresh Token만 가지고 Access Token을 발급받는 API를 만들어주어야 한다.

결론

사실 정답은 없는 것 같다. 문제 해결1을 작성할 때만 하더라도 아 진짜 깨달았다라고 생각했지만 이후에 다른 블로그를 읽으며 정말 완벽한 방어는 없구나라는 것을 깨달았다. 그래도 전보다 점점 더 안전해질 수 있는 방향을 찾아나가는 것이 개발자의 역할인 것 같다.

https://velog.io/@ohzzi/Access-Token%EA%B3%BC-Refresh-Token%EC%9D%84-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C
https://hudi.blog/refresh-token/