[REST API] 15. Token Security

1. Token 탈취

• Token은 디지털 서명을 통한 인증의 목적을 두기 때문에, Token이 탈취당하면 서버 측에서 해결할 수 없음
• 서버는 Token을 사용하여 Stateless를 유지
• 탈취당한 Token을 확인하려면, Token의 정보를 저장하고 있어야 함
• Token의 정보를 저장하고 있다 = Stateful 서버가 되어야 함
• Stateful vs Stateless는 컴퓨터 사이언스 글 참고하기
• Stateful 서버에서 토큰의 정보를 저장할 거라면 세션을 쓰는 것이 더욱 안전

2. Refresh Token

• 탈취당한 Token의 피해를 최소화하고, Stateless 서버의 이점을 유지하기 위해 설계된 것이 Access Token을 재발급하기 위한 Refresh Token

• Access Token의 만료 시간을 대폭 감소시키고, Access Token을 계속 발급할 수 있도록 인증하는 용도의 Refresh Token을 추가로 배포

• Access Token을 탈취당한다고 하더라도, 기존 Access Token보다 줄어든 만료 시간으로 인해 신원 도용으로 입는 피해가 줄어들 수 있음
• Refresh Token이 탈취당할 경우? : 기존 Access Token을 사용할 때와 똑같은 문제 발생

3. Stateful의 필요성

• 신원 도용의 문제를 해결하기 위해서는 완전한 Stateless 서버에서는 불가능

• 서버가 정말 일부라도 해당 유저의 Token 관련 정보를 가지고 있어야 비교/대조를 통해 공격자를 찾아내고 조치를 취할 수 있음

• 이때 사용할 수 있는 방법은 여러 가지가 있음

4. UX & Security

• Refresh Token의 탈취 위험성을 줄일 수 있는 방법은 여러 가지가 있으나, 대표적인 사례만 찾아본다면,

1. Refresh Token의 만료 시간 줄이기
• Access Token을 단독으로 탈취당했을 경우와 똑같은 해결책
• 서버에서 처리해야 할 일이 없고 제일 간단하게 피해를 최소화할 수 있음
• 일반 사용자도 Refresh Token을 계속 갱신하기 위해 로그인을 여러 번 수행해야 하므로 UX 저하

2. IP, User-Agent 바인딩
• 일반 사용자의 IP와 User-Agent를 DB에 저장하고, Refresh Token 재 요청 시 DB 내의 IP 및 User-Agent와 비교하여 승인 또는 거부하는 방법
• IP는 같은 기기가 아니면 절대 같을 수 없으므로 PC 환경에서 불법 접근 차단이 가능
• 모바일 앱 등에서는 기지국 위치에 따라 IP가 다르게 접속되므로 정상 사용자도 위치를 옮기면 접속이 어려워진다는 문제 발생 : UX 저하

3. 디바이스 지문 (Device Fingerprint) 추가 활용
• IP 외의 정보인 User-Agent, 기기 ID, OS, 브라우저 등의 정보를 종합하여 만든 디바이스 지문을 활용하여 DB에 저장하여 비교하는 방법
• IP를 별개로 탐지하고, 기존 접속과 동일한 기기 및 브라우저로 접속 여부를 판단
• 모바일의 경우 IP는 달라지더라도 기기가 동일하기 때문에 Refresh Token 갱신 가능
• 공격자는 디바이스 지문을 훔치지 않는 이상 Refresh Token을 갱신할 수 없음
• 이때, 디바이스 지문, IP, UA 등의 정보는 Redis에서 관리

레디스

레디스(Redis)는 Remote Dictionary Server의 약자로서[4], "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템(DBMS)이다. 2009년 살바토르 산필리포(Salvatore Sanfilippo)가 처음 개발했다. 2015년부터 Redis Labs가 지원하고 있다. 모든 데이터를 메모리로 불러와서 처리하는 메모리 기반 DBMS이다. BSD 라이선스를 따른다. DB-Engines.com의 월간 랭킹에 따르면, 레디스는 가장 인기 있는 키-값 저장소이다.[5]

https://ko.wikipedia.org/wiki/%EB%A0%88%EB%94%94%EC%8A%A4