💾 pre 스택오버플로우 클론 / JWT, 어디에 저장할까?(feat. Axios interceptor)

 

 

📂 서버-클라이언트 토큰 인증 기본 로직

• 요청 시 서버에서 헤더에 access, refresh 토큰을 담아 응답한다.
  (ex. set-cookie 헤더에 refresh 토큰을, payload에 access 토큰을 담아 응답한다)
• 클라이언트는 이 토큰들을 저장해두었다가 요청을 보낼 때 access 토큰을 보낸다.
• access 토큰이 만료되면 서버에서 만료 사인(401에러와 만료를 알리는 메세지)을 보내고
• 클라이언트는 저장해둔 refresh 토큰을 포함시켜 서버에 보낸다.
• 서버는 refresh 토큰을 확인하고, 인증되면 새로운 access, refresh 토큰을 응답으로 보낸다.
• 클라이언트는 새로 받은 토큰들로 기존 토큰을 갱신한다.
• 이후 요청은 갱신한 토큰을 사용한다.

 

 

---

 

📂  토큰 저장과 관련된 보안에 대한 짧은 지식

XSS(Cross Site Scripting)

악의적인 js 코드를 공격 당한 클라이언트의 브라우저에서 실행시키는 것으로, 브라우저에 저장된 중요한 정보를 탈취할 수 있다.

웹 상에서 가장 기초적인 취약점 공격 방법의 일종이다.

 

CSRF(Cross Site Request Forgery)

request를 가로채서 백엔드 서버에 변조된 request를 보내 악의적인 동작을 수행하는 공격(클라이언트 정보 수정, 열람)

공격 과정 예시: ima, link를 클릭한다 -> 공격자가 의도한 http request가 전송된다

 

 

---

 

 

📂 localStorage vs cookie

localStorage

장점: CSRF 공격에 안전

쿠키는 자동으로 request에 담기는 반면 localStorage의 토큰은 js 코드에 의해 헤더에 담긴다.

때문에 XSS에 취약하지 않은 이상 공격자가 클라이언트인 척 request를 보내기 어렵다.

 

단점: XSS에 취약

공격자가 localStorage에 접근하는 코드만 주입하면 탈취가 가능하다.

 

cookie

장점 1: localStorage에 비해 XSS 공격에 안전

쿠키의 httpOnly 옵션을 사용하면 JS에서 쿠키에 접근할 수 없다.

완전히 안전한 것은 아니다. 자동으로 request에 쿠키가 실리니 사용자의 컴퓨터에서 요청을 위조할 수 있기 때문이다.

XSS가 성공하면 httpOnly cookie도 안전하지 않다.

 

단점: CSRF에 취약

자동으로 http request에 담겨지기 때문에 공격자가 request url을 안다면 사용자가 link, img를 클릭하도록 유도하여 request를 위조할 수 있다. 최근에는 쿠키의 CSRF 취약점을 막기 위해 request에 자동으로 쿠키가 실리지 않는 경우도 있다.

request에 쿠키가 실리지 않는 경우에 대해 정리한 글

 

 

---

 

📂 그래서, 프론트엔드에서 토큰을 어디에 저장하지?

 

MDN은 Modern APIs의 종류인 웹 스토리지 API (localStorage와 sessionStorage) 와 IndexedDB를 사용할 것을 권장한다.

과거엔 클라이언트 측에 정보를 저장할 때 쿠키를 주로 사용하곤 했습니다. 쿠키를 사용하는 게 데이터를 클라이언트 측에 저장할 수 있는 유일한 방법이었을 때는 이 방법이 타당했지만, 지금은 modern storage APIs를 사용해 정보를 저장하는 걸 권장합니다. 모든 요청마다 쿠키가 함께 전송되기 때문에, (특히 mobile data connections에서) 성능이 떨어지는 원인이 될 수 있습니다. 정보를 클라이언트 측에 저장하려면 Modern APIs의 종류인 웹 스토리지 API (localStorage와 sessionStorage) 와 IndexedDB를 사용하면 됩니다.
출처: MDN HTTP 쿠키

+ IndexedDB: 웹 브라우저에서 제공하는 웹 애플리케이션의 클라이언트 측 데이터베이스

localStorage는 XSS에 취약하지만 CSRF에 안전하다.

반면 cookie는 localStorage에 비해 XSS 공격에 안전하지만 '완전히' 안전하지는 않고, CSRF에 취약하다.

이러한 이유에서 localStorage를 사용하기로 했다.

 

 

아래는 내가 토큰을 저장하기 위해 읽었던 블로그 글들이다.

Axios를 이용해서 Access 토큰과 Refresh 토큰을 갱신하는 방법

🍪 프론트에서 안전하게 로그인 처리하기 (ft. React)

6) React - JWT를 이용한 로그인 인증 - 2부

 

 

---

 

조사 중에 보안을 위해서는 refresh token을 사용하는 것이 가장 좋다는 결론을 얻었다.
하지만... 결론부터 말하자면 우리 팀은 백엔드 측에서 refresh token -> access token 갱신 오류를 해결하지 못했다.
어쩔 때는 토큰 갱신이 성공하고, 어쩔 때는 안되는 상황의 연속이었다.
백엔드 개발자 분이 한 명이다 보니 다른 구현 사항도 많이 남은 상황에서 필수 구현이 아닌 토큰에만 집중할 수가 없어서
refresh 토큰은 main 프로젝트에서 구현기로 했다.
+ main 프로젝트에서 만난 멘토님은 refresh token은 필수가 아니니 access token 만으로도 충분하다고 하셨다. 

당시에는 refresh token 을 구현하기 위해 처음으로 axios interceptor를 사용했다.

 

 

📂 axios interceptor

토큰이 만료된 경우에 어떤 일이 일어나는지, 프론트로 어떤 응답이 오는지,

그럼 프론트에서는 어떤 형태로 refresh토큰을 전달해야하는지 백엔드분들도 우리도 잘몰라서 정확히 모르는 상태여서 힘들었다.

그래서 서버에서 header에 두 토큰을 넘겨준다는 것, 만료 시 다시 요청을 보낸다는 것만 전제로 조사 했고,

클라이언트에서 최대한 해결을 하려고 노력 하다보니,

"만료 응답(에러)가 오면 catch 안에서 refresh 토큰을 다시 보내는" 코드를 짜려고 했다.

하지만 catch 안에서 다시 http 요청이 가능한지 확인할 수가 없었다.

그래도 그 err에 담긴 만료 여부를 읽어야만 refresh 토큰을 보낼 수 있으니,

여러 방법을 탐색하던 중, axios의 interceptor 라는 것을 발견했다.

 

interceptor는 axios의 기능 중 하나다. 요청과 응답을 중간에 인터셉트~

가로채서 무언가 살을 붙인 다음에 보낸다고 생각하면 쉽다.

 

물론 우리가 원했던, http 요청도 가능하다! 설정이 그리 어렵지 않다.

하지만 우리는 axios 인스턴스에 기본 설정 할 필요를 못느껴서 인스턴스를 만들고싶지 않았고,

요청할 때는 interceptor 기능이 필요하지 않았다. 우리가 필요한 건 딱 하나.

"응답 시 토큰 만료 에러가 생기면 intercept 해서 토큰을 갱신하고, 새로운 토큰으로 이전의 요청을 다시 보낸다" 이거였다.

 

 

그래서 이런 로직으로 구현 했다.

 

구현 중간에 기록했던 것들.

서버와 클라이언트, 서로의 사정을 모르니 하나라도 계속 공유하려고 노력했다.

 

 

---

 

📂 axios의 기능들

• 알아서 JSON 데이터로 변환 해준다.
• 헤더, 요청 주소 등 기본 설정을 한 인스턴스를 만들 수 있다.
• 요청 헤더에 기본 값을 설정할 수 있다.

 

---

 

 

참고한 글

• Axios를 이용해서 Access 토큰과 Refresh 토큰을 갱신하는 방법
• 🍪 프론트에서 안전하게 로그인 처리하기 (ft. React)
• 6) React - JWT를 이용한 로그인 인증 - 2부
• JWT는 어디에 저장해야할까
• axios interceptor로 토큰 리프레시 하기
• CSRF attacks