.gif)
JWT(JSON Web Token)를 쓴다.refreshToken은 secure httpOnly 쿠키로, accessToken은 JSON payload로 전달받는다.refreshToken을 이용해 새로운 accessToken을 받아와 웹 어플리케이션 내 지역 변수에 저장하고 사용한다.CSRF 공격과 XSS 공격에서 안전할 수 있다.
XSS 취약점을 통해 API 콜을 보낼 때는 무방비하니 XSS 자체를 막기 위해 서버와 클라이언트 모두 노력해야 함서버에서 사용자마다 다른 컨텐츠를 제공하기 위해 사용자가 누구인지 "인증"하는 과정이 꼭 필요합니다. 예를 들어 넷플릭스 홈 화면에서 사용자마다 다른 컨텐츠를 추천해주고, 관리자 페이지에 일반 사용자가 들어가지 못하도록 막기 위해서 어떤 사용자가 요청을 보냈는지 확인(검증)하는 과정이 필수적입니다. 즉, 서버에서 API 요청을 한 주체가 누구인지 확인하여 주체에 따라 다른 데이터를 제공해주기 위해 인증을 사용합니다.
이를 위해 앱(프론트엔드)에서는 자신이 누구인지를 알만한 단서를 서버에 보내야 하며, 서버는 그 단서를 파악해 각 요청에 맞는 데이터를 뿌려주게 됩니다.
현재 모바일이나 웹 서비스에서 가장 많이 쓰이는 통신 방식은 HTTP 통신입니다. HTTP 통신은 응답 후 연결을 바로 끊기 때문에 과거에 대한 정보를 전혀 담지 않습니다. (무상태성). 즉, 지금 보낼 HTTP 요청은 이전에 보냈던 HTTP 요청에 대해 전혀 알지 못한다는 말입니다. 따라서 각각의 HTTP 요청마다 주체가 누구인지에 대한 정보를 서버에 제공해야하며, 서버는 주체에 따른 응답을 클라이언트에게 보낼 수 있어야합니다.
서버에 요청을 보내는 작업은 HTTP 메세지를 보내는 것입니다. HTTP 메세지의 구조는 헤더와 바디 두가지로 구성되며, 공백은 헤더와 바디를 구분짓는 역할을 합니다. 여기서 헤더에는 요청에 대한 정보들이 들어갑니다. 바디에는 서버로 보내야할 데이터가 들어가게 됩니다. 보통 모바일/웹 서비스의 인증은 HTTP 메세지 헤더에 인증 정보(세션 or 토큰)을 넣어 요청을 보내게 됩니다.
사용자의 아이디와 비밀번호를 매 HTTP 요청마다 보내는 방식으로 보안 수준이 매우 낮은 인증방식입니다. 요청을 암호화하는 HTTPS 프로토콜을 사용하지 않으면, 해커가 요청을 중간에서 가로채 유저의 계정 정보를 그대로 탈취(중간자공격)당할 수 있는 위험한 방법입니다. 또한 브라우저의 로컬 스토리지에 아이디와 비밀번호를 저장하여 관리할 경우 XSS 공격에 의해 계정 정보가 탈취당할 수 있습니다.