JWT 관련 개발 중, JWT 토큰을 프론트엔드 단의 어디에 저장해야 하는지 찬반 의견이 갈리기에 정리해보았다.
JWT 인증 방식에 대한 설명과 이미지는 velopert님의 블로그를 참조하였다.
토큰 기반 authentication
토큰 기반 인증 방식은 기존의 Session-Cookie를 활용한 인증 방식과 달리, "stateless"하다.즉, 유저의 인증 정보를 서버나 세션에 담지 않는다.
서버 간 세션 동기화 등의 문제가 없으므로 서버를 쉽게 확장할 수 있다.
토큰 기반 인증 프로세스는 대략적으로 아래와 같다.
- 유저가 아이디와 비밀번호로 로그인
- 서버에서 계정 정보 검증하여, 정확하면 서버 -> 유저에게 signed 토큰 발급
- signed 토큰이란? '해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature 를 지니고 있다.'
- 클라이언트는 전달 받은 토큰을 어딘가에 저장해두고, 서버에 요청할 때마다 해당 토큰을 어떻게든 함께 전달
- 어딘가에? LocalStorage? Cookie?
- 어떻게? Authorization 헤더로? Cookie로?
- 서버는 토큰을 검증하고 요청에 응답
JWT 소개
JWT에 대한 설명은 여기를 참조하자.
프론트엔드에선 토큰을 어디에 저장해야 하는가?
토큰 저장 위치는 크게 두 가지 선택지가 있다 - LocalStorage, Cookie.
이 두 가지 방법에 대해 찬반이 많이 나뉘지만, 대부분의 사람들은 쿠키가 더 안전하다고 보는 것 같다.
LocalStorage
장점: 편리하다.
- LocalStorage는 Javascript로 접근할 수 있기 때문에 좀 더 편리하다. 특히, 자체 백엔드 서버를 사용할 수 있는 상황이 아니라 third-party API를 사용해야 하는 경우, pure Javascript로 접근할 수 있다.
- 클라이언트 -> 서버로 토큰 정보를 보낼 때는 Authorization header에 추가하여 보내야 한다. (ex)
Authorization: Bearer ${token}
단점: XSS 공격에 취약하다.
- XXS(Cross Site Scripting): 웹사이트에 악성 스크립트를 주입하여, 해커는 피해자의 브라우저에서 스트립트를 실행해 사용자의 세션을 가로채거나, 웹사이트 변조하거나, 악의적인 컨텐츠 삽입하거나, 피싱 공격 등을 시도하는 것을 말한다. 특히, third-part JS 라이브러리를 사용할 때 발생할 수 있다.
- LocalStorage는 Javascript로 접근할 수 있기 때문에, localStorage에 저장되어 있는 토큰을 공격자가 탈취할 수 있다.
Cookie
장점: 쿠키는 JavaScript로 접근이 불가능하다. 자동으로 HTTP 요청에 포함되어 코드가 비교적 깔끔해진다.
- Cookie 옵션 중 httpOnly 옵션을 사용한다면, 공격자는 Javascript에서 쿠키에 접근할 수 없다.
- 쿠키는 자동으로 모든 HTTP 요청에 포함되어 보내지기 때문에, 비교적 LocalStorage에서 토큰을 꺼내어 Header에 추가하는 등의 코드를 작성할 필요가 없다.
단점: 일부 케이스는 쿠키를 사용할 수 없다. CSRF 공격을 받을 수 있다.
- 쿠키는 최대 4KB의 데이터를 저장할 수 있다. 따라서 토큰의 길이가 4KB가 넘는다면 쿠키를 사용할 수 없다.
- 클라이언트 -> 서버로 토큰을 보내야 할 때 반드시 Header에 추가해야 한다면, 쿠키를 사용할 수 없다.
- CSRF(Cross Site Request Forgery): 이미 로그인된 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 웹사이트에 요청하게 하는 공격. 쿠키에 로그인 세션 정보가 담겨있는 경우 이루어진다.
그러면 어디에?
그래도 localStorage보다 Cookie가 비교적 안전하다고 하는 것 같다.
- LocalStorage 와 cookie 둘 다 XSS 공격에는 취약하다. 그러나 쿠키의 httpOnly 옵션을 사용하면 공격자가 접근하기 어렵다.
- 쿠키는 CSRF 공격에 취약하지만, sameSite 플래그와 anti-CSRF tokens를 사용한다면 어느정도 예방할 수 있다.
