토큰 기반 인증의 개념, 필요성 : 세션 기반 인증, 한계 (복습)

간단하게 복습하기

 

 - 세션 기반 인증의 동작 원리

 - 세션 기반 인증이 가지는 한계점

 - 서버 확장성 문제와 분산 환경에서의 세션 관리 어려움

 - 토큰 기반 인증의 필요성이 등장한 배경

---

세션 기반 인증 복습하기

세션 기반 인증(Session-Based Authentication) 은 전통적 웹 애플리케이션에서 가장 많이 사용되는 방식임

사용자가 로그인하면 서버는 사용자 정보를 세션에 저장하고, 브라우저는 세션 ID를 쿠키로 보관한다

세션 기반 인증

 

이 방식은 단일 서버 환경에서는 단순하고 직관적이며 많이 사용되어왔다

 

 

1. 세션 저장 구조

/session-stroe
 - sessionId0001 - > { username: "b1uffer", role: "USER"}
 - sessionId0002 - > { username: "alice", role: "ADMIN" }

 

• 서버 측 세션 저장소가 필요하다
• 세션 ID는 브라우저 쿠키로 전달되며, 서버는 이를 통해 사용자의 상태를 추적한다

 

팁

• 단일 서버 기반의 소규모 애플리케이션에서는 세션 방식이 가장 쉽고 빠르게 적용 가능하다
• 로그인한 사용자의 정보를 유지하기 위해 서버 메모리나 Redis와 같은 외부 세션 저장소를 활용해야함

---

세션 기반 인증의 한계점

세션 기반 인증은 간단하지만, 확장성과 분산 환경에서 여러 문제를 드러낸다

 

1. 서버 측 세션 저장소의 확장성 문제

모든 사용자의 로그인 상태를 서버가 관리해야 하므로, 사용자가 늘어날수록 세션 저장소가 커지고 서버 부담이 커진다

• 메모리 사용 증가 : 로그인 사용자가 많아질수록 서버 메모리에 저장된 세션 정보가 증가함
• 부하 분산이 어려움 : 서버가 여러대일 경우, 세션 동기화가 필요하다

서버 A에서 로그인한 사용자가 서버 B로 요청을 보내면, 세션 정보가 공유되지 않아서 인증 오류가 발생할 수 있다

 

 

2. 분산 환경에서의 세션 관리 문제

현대 웹 서비스는 로드 밸런서와 여러대의 서버(멀티 인스턴스)로 운영되는 경우가 많다

이 경우, 세션 관리가 매우 복잡해질 수 있다

분산 환경에서의 세션 관리 문제, 서버가 여러대임

 

각 서버가 세션 정보를 공유하지 않으면, 특정 서버에서 로그인했더라도 다른 서버에서의 인증 실패가 발생할 수 있다

이를 해결하기 위해 Redis 와 같은 분산 세션 저장소를 도입하지만,
오히려 시스템이 복잡해지고 유지보수 비용이 증가할 수 있다

 

 

팁

• 세션 공유를 위해 Sticky Session(특정 사용자를 같은 서버로 라우팅하기) 또는 Redis 와 같은 외부 세션 저장소를 사용함
• 이러한 방식은 클라우드 네이티브 환경에서 한계가 있으며, 확장성이 떨어진다