[Spring Security+JWT] JWT는 어디에 저장해야할까? localStorage vs cookie

시큐리티와 jwt를 사용한 로그인 기능까지 구현한 후, JWT를 어디에 저장하는 것이 좋을지에 대해 고민해보게 되었습니다.

 

JWT

모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰.

JWT 정보를 request에 담아 사용자의 정보 조회, 수정 등의 작업을 수행할 수 있습니다.

 

XSS (Crose Site Scripting)

악의적인 사용자가 웹 애플리케이션에 악성 스크립트를 삽입하여 사용자 브라우저에서 실행되도록 하는 공격 기법입니다.

저장형 XSS, 반사형 XSS, DOM 기반 XSS 등의 유형이 있습니다.

 

CSRF (Cross Site Request Forgery)

정상적인 request를 가로채 피해자인 척 하고 백엔드 서버에 변조된 request를 보내 악의적인 동작을 수행하는 공격 기법입니다.

- CSRF 공격이 이루어지는 과정

 

XSS 공격을 막는 것은 웹 보안을 위한 최소한의 조치이다.

아무리 다른 공격를 막아도 XSS가 뚫린다면 아무 소용이 없습니다.

JS 코드로 request를 날리거나 localStorage, 변수 값 등 모든 것의 탈취가 가능하기 때문입니다.

XSS 공격 방지는 웹 보안의 뿌리라고 할 수 있습니다.

 

---

 

🙄 JWT를 아무데나 저장한다면?

JWT는 개인정보나 다름 없는데 아무 곳에나 저장한다는 것은 보안상 매우 위험한 행동입니다. JWT는 액세스 토큰과 같은 중요한 인증 정보를 담고 있으므로, 이를 안전하게 보호해야 합니다.

 

 

🙄 JWT를 어디에 저장하는 것이 좋을까?

Local Storage와 Cookie가 있습니다.

각각의 장단점이 있으며, 상황에 따라 적합한 저장소가 다를 수 있습니다.

 

 

 

Local Storage

• 장점
  • CSRF 공격으로부터 안전합니다.
  • 세션이 끝나더라도 데이터가 유지됩니다.
  • 서버와의 통신 없이 브라우저에 저장되므로 서버 부하가 줄어듭니다.
  • 쿠키보다 용량이 크므로 더 많은 데이터를 저장할 수 있습니다.
  • JavaScript로 쉽게 접근할 수 있습니다.
• 단점
  • XSS 공격에 취약합니다.
    악성 스크립트가 실행되어 Local Storage에 저장되 데이터에 접근할 수 있습니다.
  • 데이터가 브라우저에 영구적으로 저장되므로 브라우저를 종룔해도 삭제되지 않습니다.
    보안에 민감한 정보는 저장하지 않는 것이 좋습니다.

Cooike

• 장점
  • XSS 공격으로부터 비교적 안전합니다.
    쿠키의 httpOnly 옵션을 사용하면 JS에서 쿠키에 접근 자체가 불가능하기 때문에 XSS 공격으로 쿠키 정보를 탈취할 수 없습니다.
• 단점
  • 용량이 제한되어 있어 작은 데이터만 저장할 수 있습니다.
  • 요청 시마다 쿠키가 서버로 전송되므로 트래픽이 증가할 수 있습니다.
  • Secure 및 HttpOnly 속성을 설정하지 않으면 보안에 취약할 수 있습니다.

 

---

 

💡 가장 안전한 방법?

 Refresh token은 http only secure 적용하여 Cookie에 저장 & Access Token은 로컬 변수에 저장하는 방법

=> CSRF 공격 : Cookie에 Access Token이 없어서 인증 불가 상태.  http only secure 쿠키 특성상 refresh token 자체를 털 방법이 없습니다.

=> XSS 공격 : Access Token은 로컬 변수에 저장되어 있기에 탈취 불가

 

---

 

💻 결론

브라우저에서 JWT를 저장할 수 있는 곳은 로컬 스토리지와 쿠키 두 군데가 있는데, 둘 다 자바스크립트로 읽을 수 있는 값들이기 때문에 아무런 처리 없이 저장하면 보안에 취약합니다. 

특히 로컬스토리지는 XSS를 방어할 수 있는 방법이 없기 때문에 그나마 쿠키가 보안에는 더 낫습니다. 

단, 이 쿠키는 Http Only이며 Secure(https) 옵션이 설정되어 있어야 한다. 그래야 쿠키를 자바스크립트로 읽어올 수 없고, 네트워크 감청을 통한 쿠키값 읽기를 방어합니다. 즉, XSS 공격을 통한 토큰 탈취를 방지할 수 있습니다.

 

쿠키는 브라우저가 서버에 요청을 보낼 때 자동으로 포함해서 보내는 값인데, 만약 쿠키값 안에 세션ID나 액세스토큰이 들어있다면 해커가 사용자 인증 정보를 활용해서 서버를 속여 요청을 보낼 수 있게 됩니다. ( CSRF공격 )

 

그렇기 때문에 저의 프로젝트에서는 Refresh Token만 http only secure 쿠키에 저장하고, Access Token은 프로그램상 로컬 변수에 저장하고, http 헤더에 bearer 토큰으로 담아서 매 요청마다 보내는 방법을 선택했습니다.

 

 

---

 

 

💡 Bearer 토큰은 또 뭔데?

Bearer 토큰은 OAuth 2.0 인증 프로토콜에서 사용되는 인증 토큰의 한 유형입니다.

Bearer 토큰은 단순히 클라이언트가 자원 서버에 자신을 대신하여 인증할 수 있도록 하는 문자열입니다.

 

• 획득: 사용자가 로그인하거나 인증 프로세스를 통해 서버로부터 토큰을 얻습니다. 이 토큰은 주로 액세스 토큰이며, 이를 사용하여 API에 액세스합니다.
• 전달: 클라이언트가 API 요청을 보낼 때, HTTP 헤더에 Bearer 토큰을 포함시킵니다. 일반적으로 "Authorization" 헤더에 "Bearer"라는 문자열 다음에 공백을 두고 토큰 값을 포함시킵니다.
• 인증: 서버는 클라이언트가 보낸 요청에서 Bearer 토큰을 추출하여 유효성을 검사합니다. 토큰이 유효하면 해당 요청을 처리하고, 그렇지 않으면 권한이 거부됩니다.