[HTTP] 세션과 토큰

최근 프로젝트에서 소셜 로그인 기능을 구현하게 되었습니다. 예전부터 관심이 있었던 주제였던 만큼 큰 동기부여가 되었고, 이를 바탕으로 이번 글을 작성해 봅니다. 먼저, 로그인 구현 방식의 주요한 두 가지 방법인 세션과 토큰의 차이를 살펴보고, 왜 이번 프로젝트에서는 JWT 토큰을 선택했는지 이야기해 보겠습니다.

세션과 토큰

먼저 http는 상태를 저장하지 않습니다. 이를 Stateless하다고 표현하는데 이러한 http의 특성은 서버의 수평적인 확장을 가능하게 하여 서버를 증설할 때 유리하게 작용합니다. 하지만 그렇다고 모든 기능을 Stateless하게 설계할 수는 없는데 예를 들어 로그인한 유저의 정보를 가져오기 위해서 상태유지가 꼭 필요한 로그인 기능이 대표적입니다. 그래서 일반적으로 사용자 정보가 담긴 JWT토큰을 클라이언트단에 저장하는 토큰 방식이나 세션아이디를 서버에 저장하는 세션 방식을 사용하여 구현합니다.

JWT 토큰 사용 이유

서버가 1대인 경우에는 위 그림처럼 서버(세션) 하나에 모든 클라이언트 정보가 저장 되기때문에 문제가 없지만 서비스 규모가 커져서 클라이언트의 정보를 담는 서버의 갯수가 아래의 그림처럼 늘어나면 어떻게 될까요?

 

예를 들어 클라이언트 1, 2, 3번의 정보가 각각 세션 1, 2, 3에 저장되어 있다고 생각해 봅시다. 이때 클라이언트 1번이 자신의 정보가 저장되어 있는 1번 세션이 아닌 2번이나 3번에 API 요청을 하게 되면 회원 인증 처리에 문제가 생기게 됩니다. 그래서 사용하는 것이 JWT 토큰입니다. JWT 토큰은 서버가 아닌 클라이언트 쪽에 유저 정보를 저장하는데 서버가 가지고 있는 Secret Key를 이용해 로그인에 성공한 클라이언트의 정보를 암호화 한뒤 JWT 토큰 형태로 저장합니다.

JWT 토큰 사용의 장단점

장점

1. 서버 부하 감소: 클라이언트가 정보를 저장하므로 서버 확장 및 유지 관리가 수월합니다.
2. 확장성: Stateless 특성을 유지하면서도 상태를 관리할 수 있습니다.

단점

1. 구현 복잡도 증가: JWT 발급 및 검증 로직 구현이 필요합니다.
2. 보안 문제: Secret Key가 유출되면 토큰 조작 가능성이 있습니다.
3. 토큰 탈취 위험: 토큰이 탈취되면 만료 전까지 막을 수 없습니다. 이를 보완하기 위해 Access Token과 Refresh Token을 함께 사용하는 방법이 일반적입니다.