JWT 토큰 어디에 저장하는게 좋을까?

 

 

프로젝트를 진행하면서 JWT 토큰을 어디에 저장해야 좋을까 의문이 들었다.🤔

우선 내가 경험한 프로젝트에서 토큰을 저장한 위치는 다음과 같다.

 

1. access token, refresh token 모두 로컬 스토리지에 저장
2. access token은 로컬 스토리지에 저장, refresh token은 쿠키에 저장
3. access token, refresh token 모두 쿠키에 저장

 

개발 당시에는 단순히 (코드짜기)편해서 위와 같이 설정했지만, 지금 생각해보면 보안에 전혀 신경쓰지 않았던 것 같다. 특히 로컬스토리지에 토큰을 저장했던 것은 정말 반성한다.

그렇다면 로컬스토리지에 JWT토큰을 저장하면 안되는 이유와 토큰을 어디에 저장하면 좋을지 정리해 보았다.

 

 

---

 

 

 

localStorage에 토큰을 저장하면 안되는 이유

---

1. XSS(Cross-Site Scripting) 공격에 취약

XSS란 웹 사이트 관리자가 아닌 공격자가 웹 페이지에 악성 스크립트를 삽입해 데이터를 탈취하거나 개발자가 의도하지 않은 동작을 실행시키 공격이다.

로컬스토리지는 클라이언트 측 자바스크립트 코드에서 접근 가능하다. 만약 공격자가 XSS를 통해 애플리케이션 내에서 자바스크립트를 실행한다면, 로컬스토리지에 저장된 토큰을 훔칠 수 있다.

 

 

 

2. 세션 관리의 어려움

로컬스토리지는 브라우저 세션이 종료되어도 데이터가 남아 있기 때문에, 사용자가 로그아웃을 하거나 사이트를 닫아도 토큰이 남아 있을 수 있다.

만약 로그아웃 시 로컬스토리지 토큰을 삭제하는 코드를 작성해도, 로그인 상태 이후 컴퓨터가 갑작스럽게 꺼지는 일이 발생한다면 토큰이 계속 남아있게 된다.

 

 

 

 

그렇다면 JWT토큰을 어디에 저장하는 것이 좋을까?

---

1. Cookie

HttpOnly + Secure 설정이 된 쿠키에 저장하는 것이 가장 안전하다. 쿠키는 브라우저에서 관리되므로 자바스크립트로 직접 접근할 수 없고, XSS 공격에 대한 안전성을 높일 수 있다.

• HttpOnly 속성 : 자바스크립트로 접근할 수 없으므로 XSS 공격을 방어한다.
• Secure 속성 : HTTPS 환경에서만 쿠키 전송이 가능하다
• SameSite 속성 : CSRF 공격 방어에 도움을 준다.
• 자동으로 요청 헤더에 포함되어 인증이 간편하다.
• SetCookie를 사용해 클라이언트에 전달하면 자동으로 저장되기 때문에 추가 코드가 필요하지 않다.

Set-Cookie: accessToken=abc123; HttpOnly; Secure; SameSite=Strict; Max-Age=3600

CSRF(Cross-Site Request Forgery)란 신뢰할 수 있는 사용자를 사칭해 웹 사이트에 원하지 않은 명령을 보내는 공격이다.
-MDN 문서

 

 

 

2. Refresh Token과 Access Token 분리

• Access Token : CSRF 공격에 취약하지 않도록 메모리에 저장한다. 여기서 메모리는 자바스크립트 변수나 객체를 의미한다.(전역 변수는 피해야 한다.) 관리하기 쉬운 zustand나 redux를 추천한다.
• 새로 고침 시 Access Token을 새로 받아야 하는 단점이 있다.
• Refresh Token : 위에서 설명한 HttpOnly + Secure 쿠키에 저장한다. 또는 DB(Redis)에 저장하는 방식도 있다.
• 이 경우 액세스 토큰이 필요하지 않은 요청에 토큰이 전송되는 것을 막을 수 있다.

refresh token을 db에 저장하는 경우

 

 

 

---

 

 

 

JWT 토큰을 모두 Cookie에 저장했을 때, 자바스크립트 코드가 접근 할 수 없다. (HttpOnly 속성)

 

프로젝트에서 access token의 payload에 유저Id를 넣고, 토큰을 디코딩해 유저Id를 사용하려고 했던 적이 있었다. 이 Id를 게시글 식별에 사용하고 싶었지만, HttpOnly 속성을 설정했기 때문에 자바스크립트 코드가 접근할 수 없어 애먹었던 경험이 있다.😂

 

이때는 그냥 API로 유저 정보를 받으면 된다. 유저 정보를 요청하는 API를 보내면(로그인 후 access token이 cookie에 저장되어 있다고 가정) 요청 헤더에 쿠키가 포함되고, 서버에서는 토큰을 받아 디코딩한다. 그리고 payload에 있는 유저Id를 가지고 요청을 보낸 사용자가 누구인지 판단하는 것이다.

 

토큰 디코딩을 꼭 클라이언트에서 해야한다는 생각이 너무 컸던 것 같다.