Access Token과 Refresh Token의 저장 위치

1년 전에 한참 졸업 프로젝트, 창업동아리 활동을 하면서 세션 기반 로그인, JWT 기반 로그인, Access Token과 Refresh Token의 개념을 공부했었다. 오늘 자율 프로젝트에서 로그인 기능을 맡아 오랜만에 다시 생각나서 정리해본다ㅎㅎ
 
우선, 웹은 본질적으로 무상태(stateless)로 동작하기 때문에 이런 로그인 과정이 필요한 것이다. HTTP 프로토콜 자체가 무상태(stateless)하기 때문에 서버는 클라이언트의 각 요청을 독립된 요청으로 처리한다. 즉, 사용자의 인증 정보를 확인할 방법이 필요하며 이러한 방법들이 세션 기반 로그인, JWT 기반 로그인인 것이다.
 
세션 기반 로그인 방식은 클라이언트에는 세션 ID만 저장하고 서버에 중요한 사용자 정보를 저장한다. 세션 ID 자체에는 중요한 정보를 가지고 있지 않기 때문에 보안성의 측면에서는 비교적 안전하다고 할 수 있다. 하지만 사용자가 많아질수록 서버에 저장할 데이터가 커지는 문제가 발생할 수 있다.
 
JWT 기반 로그인 방식은 클라이언트 측에서 Access Token과 Refresh Token을 들고 있는다. 서버는 Access Token의 값을 저장하지 않으며 서명을 검증하여 유효한지 확인한다. 따라서 중요한 내용을 포함한 Access Token이 탈취되면 위험이 크므로 Access Token의 유효 기간을 짧게 설정하고 필요 시 Refresh Token을 통해 재발급 받는 전략을 사용한다. 하지만 Refresh Token 또한 클라이언트 측에 저장되므로 탈취될 위험이 있으며, Access Token과 Refresh Token 모두 사용자의 인증 정보와 관련된 중요한 정보를 포함하고 있기 때문에 탈취되지 않도록 보안을 신경쓰는 것이 중요하다.

	세션 기반 로그인	토큰 기반 로그인
보안성	서버에 중요한 정보가 저장되므로 상대적으로 안전하다.	클라이언트에 중요한 정보가 저장되므로 보안에 신경써야 한다.
확장성	비교적 제한적이다	비교적 높다
상태 유지	서버가 상태 관리	클라이언트가 상태 관리
로그아웃 관리	서버에서 세션 만료 가능	즉각적 무효화 어려움

 
그렇다면 Access Token과 Refresh Token을 안전하게 보관하기 위해서는 클라이언트의 어디에 저장하면 좋을까?
오늘 이러한 생각을 했다.
1. Cookie가 localStorage보다는 안전하다.
2. 그렇다면 Access Token과 Refresh Token을 모두 Cookie에 저장해도 되는가? 
 
쿠키가 로컬 스토리지보다 안전한 이유는 다음 3가지 이유에서 XSS, CSRF 공격에 더 잘 대응할 수 있어서이다.
- HttpOnly 속성: 쿠키에 HttpOnly 속성을 적용하며 JavaScript로 접근할 수 없게 되어, XSS 공격에 더 잘 대응할 수 있다. 즉, 공격을 받더라도 쿠키를 탈취당할 위험을 줄일 수 있다.
XSS 공격이란? Cross-Site-Scripting 공격으로 공격자가 악의적인 스크립트를 실행하도록 하는 것이다. 이를 통해 공격자가 사용자의 세션 혹은 쿠키 정보를 얻을 수 있다. HttpOnly 속성은 공격자가 JavaScript를 통해 중요한 정보를 탈취당할 위험을 줄이는 역할을 한다.
- Secure 속성: 쿠키에 Secure 속성을 설정하면 HTTPS 연결에서만 전송되도록 제한할 수 있다.
- SameSite 속성: 쿠키에 SameSite 속성을 설정하면 동일 출처 내에서만 쿠키가 전송되도록 제한할 수 있다. 이를 통해 CSRF 공격에 비교적 잘 대응할 수 있다.
CSRF 공격이란? Cross-Site Request Forgery으로 사용자가 인증된 상태임을 악용하여 사용자의 권한으로 의도하지 않은 요청을 실행하는 공격이다. 이를 통해 사용자의 권한을 탈취당할 수 있다.
 

1. XSS(Cross-Site-Scripting) 공격
: 주로 변조 혹은 위조 공격에 해당한다.
: 클라이언트 측 스크립트를 악의적으로 조작한다. 공격자가 웹 페이지의 JS, HTML 등을 악의적으로 수정하거나 브라우저에 악성 스크립트를 삽입해 공격한다. 이를 통해 토큰을 탈취할 수 있다. 만약 쿠키에 HTTPOnly 설정이 되어 있다면 JavaScript를 통해서 쿠키를 읽을 수 없기 때문에 XSS 공격을 방지할 수 있다. localStorage 같은 경우는 XSS 공격에 매우 취약하다.

1. CSRF(Cross-Site Request Forgery) 공격
: 주로 위조 공격 유형에 해당한다.
: CSRF는 공격자가 사용자의 신뢰된 연결 정보를 활용하여 몰래 의도하지 않은 작업을 수행하도록 하는 공격이다. 사용자의 권한으로 악의적인 사이트(도메인)에 요청을 보내 의도하지 않은 작업을 하도록 할 수 있다. 쿠키에 SameSite 속성을 적용한다면 다른 도메인으로의 쿠키 전송을 막아 CSRF 공격을 방지할 수 있다.

 

그렇다면 Access Token과 Refresh Token을 모두 쿠키에 저장하면 안되는 것인가?
Access Token과 Refresh Token을 모두 쿠키에 저장하면 동시에 탈취당할 수도 있어 위험할 수도 있다고 한다. 따로 저장해야 한다면 가장 안전한 방법은 Access Token을 메모리에 저장하고, Refresh Token은 쿠키에 저장하는 방법일 수도 있다. 하지만 이 경우 새로고침 시에 매번 Access Token이 사라지는 문제가 발생할 수 있어 조금 비효율적일 수도 있다고 생각한다. 그렇다면 Access Token은 localStorage에 Rrefresh Token은 쿠키에 저장할 수 있다. 이렇게 하면 따로 저장하며 토큰이 동시에 탈취당할 위험을 줄일 수 있고, Access Token이 탈취당하더라도 비교적 유효 기간이 짧기 때문에 피해를 줄일 수 있다. 하지만 localStorage에 Cookie에 비해 보안에 취약한 것은 사실이고, 위 방법을 사용한다고 해서 보안 위협을 완전히 제거할 수 있는 것은 아니다.
 
결론적으로 많은 글을 읽어보았을 때 완벽한 보안은 없다라는 결론을 내릴 수 밖에 없다. JWT를 사용하기로 한 순간부터 보안의 위협을 완전히 제거할 수는 없고, 이를 최소화하는 것을 목표로 해야 하는 것 같다.(사실 세션 기반 로그인을 사용해도 보안에는 신경써야 한다.) 따라서 Access Token과 Refresh Token을 어떻게 안전하게 보관할지 고민하고, 탈취를 대비하는 방안을 마련하는 것이 중요하다. 예를 들어, Refresh Token Rotation(RTR - Refresh Token을 한 번 사용할 때마다 새로운 Refresh Token을 발급하고 이전 토큰을 무효화하는 방식)을 사용하거나, Refresh Token으로 Access Token을 재발급할 때 다중 인증(MFA)을 도입해 공격에 대응할 수 있다. 이러한 보안 조치들을 통해 잠재적인 위협에 최대한 대비하는 것이 중요한 것 같다.
 
참고
https://seungyong20.tistory.com/entry/JWT-Access-Token%EA%B3%BC-Refresh-Token-%EA%B7%B8%EB%A6%AC%EA%B3%A0-RTR-%EA%B8%B0%EB%B2%95%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90