[Network]세션 기반 인증 vs. 토큰 기반 인증

지난 글에서 HTTP의 비연결성(Conectionless)과 무상태성(Stateless)을 극복하기 위한 방법으로써의

 

쿠키, 세션과 보안과정인 TLS, 그리고 그것이 적용된 HTTPS의 통신 방식에 대해서 살펴보았다.

 

여기서 비연결성과 무상태성이란

 

• Connectionless - 클라이언트가 요청을 한 뒤 응답을 받으면 서버가 연결을 끊어버리는 특성
• Stateless - 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며, 상태 정보를 유지하지 않는 특성

을 말하며, 쿠키와 세션을 이용한 극복은 연결 및 상태를 유지하는(Stateful) 방식으로 이루어졌다.

 

2022.08.03 - [Development/Network] - [네트워크]웹(WEB)

2022.08.04 - [Development/Network] - [네트워크]HTTP

2022.09.20 - [Development/Network] - [Network]TLS, HTTPS

2022.09.20 - [Development/Network] - [Network]쿠키(Cookie)

2022.09.20 - [Development/Network] - [Network]세션(Session)

[Network]세션(Session)

하지만 이 같은 방식은 잘 작동하긴 하지만 REST API를 이용한 CSR 방식과는 어울리지 않았는데,

 

쉽게 말하면 SPA를 이용하지 못해 사용자 경험(UX) 및 서버 부하 차원에서 좋지 않았다는 뜻이다.

 

SSR과 CSR의 차이점은 지난 글에 정리해두었다.

 

2022.08.03 - [Development/Network] - [네트워크]SSR vs. CSR

[네트워크]SSR vs. CSR

 

이 글에선 위와 같은 전통적인 세션 기반 인증 방식을 극복한 토큰 기반 인증과 그 장단점에 대해서 살펴본다.

 

Session-Based Authentication vs. Token-Based Authentication

 

위 그림은 세션 기반 인증과 토큰 기반 인증 방식을 단순화시켜서 나타낸 것이다.

 

로그인 인증 요청 시서버가 쿠키와 세션을 전달하는 것과 토큰을 전달하는 것, 그리고

 

이후의 요청시 클라이언트가 세션ID를 전달하는 것과 토큰을 전달하는 것 말고는 크게 차이점이 없어 보인다.

 

구체적으로 어떤 차이가 있는지 지금부터 천천히 구체적으로 살펴보자.

 

Session-Based Authentication

 

전통적인 세션 기반 인증방식의 가장 큰 특징은 인증된 사용자의 정보를 서버 쪽 세션 저장소에 저장한다는 것이다.

 

로그인 요청이 들어와 인증이 끝난 후 서버는 세션을 생성 및 저장하고 그 세션을 식별할 세션ID를 쿠키에 담아 반환한다.

 

사용자는 쿠키를 저장하고 있다가 이후의 요청에 세션ID를 담아 보내는데,

 

이때 서버 측에 저장된 세션 정보와 사용자가 제공한 세션ID가 일치하는지 확인하는 식으로 검증이 이루어진다.

 

이 방식의 추가 특징은 아래와 같다.

 

• 클라이언트는 세션ID만 사용하기 때문에 상대적으로 네트워크 부하가 적다.
• 인증 정보를 서버에서 관리하기 때문에 상대적으로 보안이 강하다.
• 세션 데이터가 많아질수록(사용자가 늘어날수록) 서버의 부담이 가중된다.
• 서버 확장 시 세션 불일치(정합성) 문제가 발생할 가능성이 높다.
  
  
  • 이를 방지하려면 모든 서버가 해당 사용자의 세션을 공유해야 한다.
  • 혹은 Sticky Session, Session Clustering, 저장소의 물리적 분리 등의 방법이 있다.
• SSR(Server Side Rendering)에 적합한 방식이다.

계속해서 위의 단점들을 극복한 토큰 기반 증명 방식에 대해 알아보자.

 

Token-Based Authentication

 

토큰(Token)은 직역하면 징표, 기념품 등의 뜻을 가지며 상품권이나 서비스의 교환권을 뜻하는 영어 단어이다.

 

쉽게 말해 적절한 자격 증명 시 발급되는 놀이공원 입장권이라고 생각하면 된다.

 

애플리케이션 인증에서의 토큰도 비슷한 뜻으로 이용되는데,

 

올바른 크리덴셜을 제출하고 서버에서 발급받는 임시 출입증이라는 점에서 그렇다.

 

임시 출입증은 당연하게도 권한이 정해져 있어 모든 곳에 출입이 가능하지는 않다.

 

이처럼 서버에서 발급받는 토큰도 자격 증명을 하는 동시에 접근 권한을 제한하고 있으며

 

특정 리소스로의 접근만 허용하게 된다.

 

토큰 기반 인증 방식은 위와 같은 순서로 처리되는데,

 

가장 먼저 눈에 띄는 점은 세션 저장소가 사라졌다는 데 있다.

 

토큰 기반 인증 방식의 가증 큰 차이점은 인증된 사용자 정보를 서버 측에서 관리하지 않는다는 것이다.

 

즉, 인증된 사용자의 상태를 유지할 필요가 없다는 뜻이다.

 

로그인 요청이 들어와 인증이 끝난 후 서버는 토큰을 생성하고 서명을(Sign) 해서 사용자에게 돌려주며

 

사용자는 이후의 요청에 토큰을 담아서 보내게 된다.

 

이 토큰은 만료되기 전까지는 무효화시킬 수 없는데, 보안을 위해 만료시간을 짧게 주고 Refresh Token을 발급하기도 한다.

 

또한 서버는 사용자가 제출한 토큰을 확인하는 식으로 검증을 하게 된다.

 

이 방식의 추가 특징은 아래와 같다.

 

• 토큰에 인증된 사용자 정보가 담겨 있어 상대적으로 네트워크 부하가 크다.
• 토큰을 서버 측에서 관리하지 않으므로 상대적으로 보안이 취약하다.
• 사용자가 많아져도 서버에 부담이 상대적으로 덜하다.
• 서버의 확장성이 뛰어나고, 세션 불일치 같은 문제가 발생하지 않는다.
• 토큰에 포함되는 정보는 암호화가 되지 않기 때문에 민감한 정보를 담을 수 없다.
• CSR(Client Side Rendering)에 적합한 방식이다.

 

Summary

 

	세션 기반 인증	토큰 기반 인증
네트워크 부하	적음	큼
보안	강함	취약
서버 부담	큼	적음
서버 확장성	작음	큼
렌더링 방식	SSR	CSR