JWT: JWT와 Session

프로젝트를 진행하다보면 매번 Authentication 인증 인가 방식에서 당연하게 JWT를 사용하곤 헀다. 

하지만 JWT의 정확한 장점과 Session의 차이점을 더 명확하게 이해한다면 프로젝트에 따라, 인증 인가를 효율적으로 사용할 수 있을 것 같아 작성하게 되었다.

---

JWT (JSON Web Token)

정의:

JWT는 JSON 형식의 데이터를 사용하여 클라이언트와 서버 간에 정보를 안전하게 전송하기 위해 설계된 토큰 기반 인증 방식.

구조:

1. Header: 토큰의 타입(JWT)과 서명 알고리즘 정보(e.g., HMAC, RSA 등).
2. Payload: 사용자 정보나 클레임(Claims) 데이터가 포함된 부분.
3. Signature: 헤더와 페이로드를 비밀 키로 암호화한 서명.

특징:

1. 토큰 자체에 정보 포함:
   • 클라이언트와 서버 간의 요청마다 정보를 저장하지 않고, 토큰 자체에 사용자 정보를 포함
2. 무상태 (Stateless):
   • 서버에서 상태를 저장하지 않으므로 확장성에 유리
3. 보안:
   • 서명(Signature)을 통해 토큰 변조를 방지
   • 그러나 페이로드는 암호화되지 않으므로 민감한 데이터는 제외할것.
4. 사용 예시:
   • OAuth2 인증, API 인증, 분산 시스템.

세션(Session)

정의:

세션은 서버가 클라이언트의 상태 정보를 메모리나 데이터베이스와 같은 저장소에 저장하여 관리하는 방식으로 클라이언트는 세션 ID를 통해 서버에서 자신의 상태를 조회할 수 있음.

작동 방식:

1. 클라이언트가 서버에 로그인 요청
2. 서버는 사용자를 인증한 후 고유한 세션 ID를 생성하고 이를 서버에 저장
3. 클라이언트는 세션 ID를 쿠키에 저장하여 요청 시마다 전달
4. 서버는 세션 ID를 확인하여 클라이언트의 상태를 파악

특징:

1. 서버 측 저장:
   • 클라이언트 상태를 서버가 유지하므로 무상태가 아님
2. 보안:
   • 민감한 데이터를 서버에서 직접 관리하므로 상대적으로 안전성 UP
3. 확장성 문제:
   • 서버가 상태를 저장해야 하므로 사용자 수가 많아지면 확장성 저하
4. 사용 예시:
   • 웹 애플리케이션 로그인, 장바구니 시스템.

---

여기까지가 JWT와 세션의 정의인데, 두 방식의 차이점을 더 명확하게 비교해보도록 하겠다.

 

JWT와 세션의 비교

특징	JWT	Session
상태 관리	무상태 (Stateless)	상태 유지 (Stateful)
정보 저장 위치	클라이언트 (토큰 내부)	서버 (세션 저장소)
확장성	뛰어남 (서버 부하 적음)	낮음 (서버 부하 많음)
보안	페이로드가 암호화되지 않음	민감 데이터 서버에서 관리
토큰 크기	크기가 클 수 있음 (페이로드 포함)	세션 ID는 작음
사용 사례	분산 시스템, RESTful API	단일 서버 기반 애플리케이션

 

사실 여기서 우리가 보통 프로젝트에서 인증 인가를 JWT로 처리를 하는 이유가 명확하게 나와있는데 바로 '확장성' 부분이다. 

즉, Session 같은 경우에는 세션 정보를 서버의 DB에 주기적으로 동기화를 해줘야한다. 때문에 단일 서버에서만 인증 인가 처리가 가능하지만 JWT같은 경우에는

• JWT는 클라이언트가 토큰에 모든 인증 정보를 포함하여 서버에 요청을 보냄
• 서버는 해당 토큰의 서명만 검증하고 요청을 처리하므로, 따라서 상태 정보를 별도로 저장할 필요가 없음

때문에 서버 간 데이터 동기화가 필요 없으므로 분산 시스템 혹은 다중 서버를 두어도 기존과 마찬가지로 똑같이 인증 인가 처리를 할 수 있고 이것을 확장성이 뛰어나다 라고 할 수 있다.

 

---

사실 이정도면 굳이 세션을 사용할 이유를 찾기가 어렵다. 물론 단일 서버 기반이라면은 보안적인 부분에서는 좀 더 우수하다고 할 수 있겠지만 요즘같은 IT서비스에서는 단일서버로 운영한다는 것은 거의 찾아보기가 힘들다. 

그래도 만일 세션을 활용할 수 있는 프로젝트나 서비스가 있다면 한번쯤은 도전해보고 싶다.