들어가며
로그인은 JWT토큰 사용하는 걸로 해요. 네~ 좋아요. 그런데 왜 JWT토큰으로 고르셨어요?
약간의 각색이 있긴 하지만 내가(백엔드) 프론트와 협업하며 했던 대화이다. 그냥 던져본 질문일 텐데 순간적으로 대답이 잘 나오지 않더라. 이번 기회에 협업 과정에서 어떤 식으로 소통했는지, 어떻게 이야기하면 좋은지를 정리하며 jwt토큰을 이용한 로그인에 대해 정리해두고자 한다. 사실 검색해보면 많이 나온다. 내 방식대로 정리하고 싶고, 내가 왜 선정했는지를 기록하고자 남겨본다.
쿠키, 세션, 토큰 로그인
쿠키 (Cookie):
특징:
- 클라이언트 측에 저장되는 작은 데이터 조각으로, 서버가 클라이언트에게 전송
- 브라우저는 쿠키를 저장하고, 요청 시에 자동으로 서버에 전송
- 주로 세션 식별, 사용자 환경 설정 등에 사용
장단점:
- 장점:
- 쉽게 사용 가능하며 구현이 간단
- 상태를 유지할 수 있어 사용자 경험을 향상시킬 수 있다
- 단점:
- 보안 이슈: 쿠키는 클라이언트에 저장되기 때문에 민감한 정보를 담기에 적절하지 않다 !!
- 용량 제한: 브라우저에 저장 가능한 크기에 제한이 있음
세션 (Session):
특징:
- 서버 측에 사용자 정보를 저장하는 방식으로, 세션 식별자가 클라이언트에 전송되고, 서버에서 세션 데이터를 관리
- 쿠키를 통해 세션 식별자를 클라이언트에 저장하거나 URL에 식별자를 추가하여 사용
장단점:
- 장점:
- 서버에 정보를 저장하기 때문에 보안성이 높다
- 쿠키보다는 더 많은 데이터를 저장할 수 있다
- 단점:
- 서버 자원 소비: 많은 사용자가 접속할 경우 서버 메모리를 많이 차지
- 확장이 어려움
토큰 (Token):
특징:
- 클라이언트가 서버에게 식별 정보를 제공하는 방식으로, 주로 JWT(JSON Web Token)를 사용
- 클라이언트가 토큰을 갖고 있어야 하며, 서버는 토큰의 유효성을 검증
장단점:
- 장점:
- 서버에 저장할 필요가 없어 서버 부하가 감소하며, 서버의 확장성이 좋음
- 분산 시스템과의 통합이 용이
- 단점:
- 토큰이 클라이언트에 저장되므로, 클라이언트 측의 보안성이 중요
- 토큰이 서버에서 관리되지 않기 때문에 유효 기간과 같은 보안 문제에 주의
토큰의 유효기간 / 서버에서 관리되지 않는 문제 등을 해결하기 위해 보통 리프레시 토큰을 함께 사용한다.
사실상 쿠키는 이제 거의 사용하지 않는 방식이고, 세션과 토큰 중에서 만들고자 하는 서비스에 더 어울리는 것으로 상의하여 고르면 된다.
그래서 왜 JWT토큰 방식을 골랐을까?
세션과 토큰 중에서 골라야 했는데 큰 차이점이 있다면 서버에 정보를 저장하느냐 그렇지 않느냐이다. 이 부분 때문에 멀티디바이스 및 크로스플랫폼 환경에서 토큰에 장점이 있다. 멀티디바이스 환경에서 토큰 기반의 인증은 클라이언트 중심 관리와 유연한 멀티디바이스 지원, 그리고 분산 시스템과의 통합 용이성 등으로 인해 많은 이점을 가진다. 특히 최근 웹 애플리케이션에서는 OAuth 2.0 및 OpenID Connect와 같은 표준을 사용하여 토큰 기반의 인증이 널리 사용되고 있어 보편적이기도 하다.
개인적으로 가장 중요한 선정 이유는 '멀티디바이스'상태에서의 편리함에 있다. 세션은 서버에서 상태를 관리하니 클라이언트가 늘어날수록 서버 부하가 커지고, 중복 로그인 등에 대해 별도의 인증 관리 등이 필요하다.
만약 내가 A기기와 B기기에서 동시에 로그인을 시도한다고 하자. (요즘 흔하다. 컴퓨터, 폰, 태블릿 노트북 기타등등 ...) 세션은 요청이 올때마다 서버에서 인증된 유효한 사용자인지 해당 세션에 대해 검사를 진행하므로 서버에 세션 정보를 저장한다. A기기의 B기기 각각 로그인하면 세션 정보를 각각 저장해야 한다. 그렇다면 사용하는 디바이스가 늘어날수록 정보는 커지고, 모든 디바이스의 세션을 동기화해야하는 거 아닌가? ...여기까지 생각한 후 토큰 방식으로 진행하기로 마음먹었다. 토큰 방식은 멀티디바이스에 대한 별도의 부담이 (거의)없다.
