목차
인증과 인가 시스템을 설계할 때 보안, 확장성, 그리고 사용 편의성을 모두 고려해야 한다. JWT는 별도의 세션 상태를 서버에 저장하지 않아도 되는 장점이 있어 분산 환경에서 유리하다. 일반적으로 토큰을 관리할 때 로컬 스토리지, 세션 스토리지, 쿠키 세 가지 방법을 사용한다.
세 가지 방법 중 프로젝트를 진행하며 클라이언트 측에는 쿠키를 활용해 토큰을 저장하고, 서버에서는 Redis로 토큰의 상태와 만료를 관리하는 방식을 적용한 것에 대해 이야기하려 한다.
JWT (JSON Web Token)
JWT는 다음과 같이 세 부분(헤더, 페이로드, 서명)으로 구성된다.
•
헤더(Header): 토큰의 타입과 해싱 알고리즘 정보를 담는다.
•
페이로드(Payload): 사용자 ID, 역할, 발급 시간, 만료 시간 등의 정보를 클레임으로 포함한다.
•
서명(Signature): 비밀키를 사용해 헤더와 페이로드를 해싱하여 변조를 방지한다.
JWT를 사용하면 서버에 별도의 세션 정보를 저장하지 않아도 되고, 토큰 자체에 필요한 정보를 담기 때문에 분산 시스템에서 효율적으로 인증을 수행할 수 있다. 다만, 토큰 만료 시 재발급 로직이 필요하고, 토큰 탈취에 대한 보안 대책이 요구된다.
그래서 등장한 것이 Access Token과 Refresh Token이다. 서버는 Access Token를 통해 사용자를 인증한다. 따라서 Access Token은 상대적으로 짧은 만료 시간을 가진다. 짧은 만료 시간으로 인해 노출되더라도 피해를 최소화할 수 있다. Refresh Token은 Access Token이 만료된 후 새로운 Access Token을 발급받기 위해 사용되는 토큰으로, 더 긴 만료 시간을 가진다.
쿠키를 이용한 토큰 관리
쿠키란?
쿠키는 웹 브라우저에 데이터를 저장하는 표준 메커니즘이다. HTTP 요청 시 쿠키가 자동으로 포함되어 서버에 전송되므로, 상태 정보를 유지하는 데 유용하다. 내가 토큰 관리를 구현할 때는 다음과 같은 이유로 쿠키를 선택했다.
•
보안 옵션 적용 가능: HttpOnly와 Secure 옵션을 설정하여 XSS 공격이나 중간자 공격에 대한 방어가 가능하다.
•
자동 전송: 별도의 코드 없이 매 요청 시 서버로 자동 전송되어 인증 토큰 관리가 편리하다.
쿠키, 로컬 스토리지, 세션 스토리지 비교
각 저장소의 특징을 표로 정리하면 아래와 같다.
저장소 | 장점 | 단점 |
쿠키 | - 서버와 자동 전송
- HttpOnly, Secure 설정 가능 | - 모든 요청에 전송되어 오버헤드 발생
- 탈취에 취약 |
로컬 스토리지 | - 비교적 큰 용량 지원
- 브라우저에 영속적 저장 | - HttpOnly 옵션이 없어 자바스크립트 접근 가능
- XSS 공격 취약 |
세션 스토리지 | - 탭 단위로 데이터를 관리
- 브라우저 세션 동안만 유지 | - 브라우저나 탭 종료 시 데이터 소멸
- 다른 탭과 공유 불가
- XSS 공격 취약 |
쿠키는 보안 측면에서 HttpOnly 옵션을 적용할 수 있기 때문에 인증 토큰 관리에 적합하다. 반면, 로컬 스토리지는 용량이 크지만 보안에 취약하여 민감한 정보 저장에는 부적합하다. 세션 스토리지는 탭 간 데이터 공유가 되지 않는 점 때문에 사용 범위가 제한적이다.
Redis를 활용한 인증 데이터 관리
Redis의 역할
Redis는 인메모리 데이터베이스로, 빠른 읽기/쓰기가 가능하며 데이터 만료(expire) 기능을 제공한다. 이러한 특성 덕분에 JWT 토큰 관리에 매우 적합하다.
•
빠른 조회 및 갱신: 인증 토큰과 관련 데이터를 실시간으로 관리할 수 있다.
•
만료 관리: Redis의 TTL(Time To Live)을 활용하여, 일정 시간이 지난 토큰을 자동 삭제할 수 있다.
•
데이터 인덱싱: Secondary Index 기능을 통해 다양한 조건으로 데이터 검색이 가능하다.