토이 프로젝트에서 로그인 인증 방식을 JWT를 활용하여 구현을 하였다. 이번 포스트를 시작으로 JWT를 차근차근 정리를 해보겠다. 이번 포스트에는 JWT에 간단한 설명과 함께 주의해야 할 점을 작성해보았다.
세션 기반 인증, 토큰 기반 인증
로그인 인증 방식을 구현할 때 세션 기반 인증 또는 토큰 기반 인증의 방법을 많이 사용하게 되는데 우선 이 둘의 차이점을 정리해 보았다.
세션 기반 인증은 사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다. 사용자가 로그인을 하면 해당하는 세션ID를 발급하여 세션 저장소에 저장하고 사용자에게 전달한 후 사용자가 로그인 인증이 필요할 때 마다 발급받은 세션ID를 HTTP Cookie 헤더에 담아 보내게 되면 서버에서 세션 저장소에 해당하는 세션ID의 유무를 확인하고 진행하는 방식이다.
토큰 기반 인증은 세션 기반과 다르게 인증 정보를 클라이언트의 로컬 스토리지(혹은 쿠키)에 저장 하게 된다. 이를 HTTP Authorization헤더에 담아 보내면 서버에서 위변조 확인과 만료기간을 확인하여 진행하는 방식이다.
차이점
크기
세션 기반은 세션ID를 HTTP Cookie 헤더에 담아 보내기만 하면 되지만 토큰 기반인 경우에는 사용자 인증 정보와 토큰의 발급시각, 만료시각, 토큰의 ID등 담겨있는 정보가 세션 ID에 비해 비대하므로 세션 방식보다 훨씬 더 많은 네트워크 트래픽을 사용한다.
보안성
세션의 경우에는 데이터를 서버에 가지고 있기 때문에 보안적인 면이 더 우수하고 혹여 세션ID를 탈취당하더라도 서버에서 세션을 무효처리 할 수 있다. 하지만 토큰의 경우 클라이언트가 데이터를 가지고 있어 보안이 취약할 수 있고 탈취를 당했다면 토큰이 만료되기 전까지 피해가 지속될 수 있다.
확장성
세션의 경우 데이터를 서버에 가지고 있다 하지만 최근에는 MSA를 기반으로 하나의 서버가 아닌 여러개의 서버를 활용하게 되는데 이런 경우에 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 통해 세션 불일치 문제를 해결해야 한다.
서버의 부담
세션의 경우 데이터를 서버에 가지고 있으므로 관리해야 할 세션ID가 많아 질수록 세션 저장소의 접근이 많아져 서버의 부담이 커질 수 있다.
JWT 사용 시 유의할 점
-
HEADER에 알고리즘에 'None'을 입력하거나 시크릿 키를 단순하게 작성하게 되면 보안에 취약하고, JWT 디코딩이 매우 간단하므로 보안성이 높은 데이터는 넣지 않고 최소한의 데이터만 넣어야 한다.
-
JWT를 탈취를 방지하거나 탈취당했을 때를 대비해야 한다.
1. 클라이언트의 HttpOnly cookie에 토큰을 저장한다.- JWT 블랙리스트 기능을 구현한다.
- JWT의 만료기간을 짧게 설정한다.
- refresh token rotation을 사용한다.
참고 문서 및 링크
