세션(Session)과 토큰(Token)에 대해서

📍 들어가기 전 

웹 환경에 사용자와 시스템 간 데이터를 교환하기 위해 HTTP 방식을 사용합니다. HTTP통신은 요청과 응답에 의해 동작하며, HTTP 특징 중 가장 중요한 특징은 바로 Stateless입니다. Stateless는 문자 그대로 State(상태) + less(없음)을 의미합니다. 

 

각 HTTP 통신은 독립적으로 과거 통신(요청 및 응답)에 대한 내용을 전혀 기억하지 못합니다. 따라서, 매 통신마다 필요한 모든 정보를 담아 요청을 보내야 한다는 것입니다. 만약 로그인 후 상품 구매나 상품을 찜하기에 저장하는 것과 같이 여러 통신(요청/응답)의 진행 과정에서 연속된 데이터 처리가 필요한 경우 Stateless의 특징에 따라 매번 로그인을 위한 인증정보를 같이 보내주어야 합니다. 이런 불편함을 없애기 위해 일부 정보에 대해 StateFul 한 상태를 유지해야 합니다. 유지를 위해 Session과 Cookie 또는 Token 같은 기술을 사용할 수 있습니다.

 

 

1. Session & Cookie에 대해서

1️⃣ Session이란? 

Session은 서버 측에 사용자의 상태를 유지하기 위한 기술입니다. 동일한 클라이언트(사용자)가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료해 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나의 상태로 보고, 그 상태를 일정히 유지해 클라이언트와 웹 서버가 논리적으로 연결된 상태를 뜻합니다. 

서버는 Session에 대한 정보를 저장하고 클라이언트에게 Session을 구분할 수 있는 고유한 ID를 부여하는 데 이를  Session ID라고 합니다.  클라이언트는 Request를 보낼 때 해당 Session ID를 함께 보내 클라이언트의 상태를 확인할 수 있습니다. 

 

2️⃣ Cookie 란? 

Cookie는 클라이언트(사용자의 브라우저)에 저장되는 작은 데이터 조각입니다. Cookie에는 이름, 값, 만료 날짜/시간(저장기간), 경로 정보 등으로 구성되어 있으며 하나의 도메인 당 20개를 가질 수 있습니다. 1개당 4Kbyte를 넘길 수 없다는 특징이 있습니다.  

서버에서 HTTP Response Header에 Set-Cookie 속성을 이용해 클라이언트에 Cookie를 제공해 저장하고 클라이언트는 HTTP Request에 저장된 Cookie를 함께 전달해 이전 통신에 사용된 정보를 파악할 수 있습니다. 

예를 들어, 장바구니 기능은 과거에는 로그인을 해야 사용이 가능했지만 Cookie를 이용해 로그인 하지 않은 상태로 장바구니에 상품을 담을 수 있게 되었습니다. Cookie를 통해 사용자별로 다른 정보를 표시하는 것이 가능하고, 사용자의 행동과 패턴을 분석할 수 있어 최근 들어 더 중요한 개념이 되었습니다. 

 

 

3️⃣ Session & Cookie를 사용한 인증(Authentication) Flow

1) 사용자가 로그인 페이지에 로그인 정보(아이디, 패스워드 등)을 입력

2) 서버는 입력된 정보를 검증하고 유효한 경우 사용자에 대한 정보(사용자 ID 등)를 세션에 저장

3) 동시 서버는 Session ID를 생성하고, 이를 Cookie에 담아 사용자 브라우저로 전송(HTTP Response Header의 Set-Cookie 속성을 이용해 사용자에게 전달)

4) 브라우저는 서버로부터 받은 쿠키를 저장

5) 쿠키는 브라우저의 쿠키 저장소에 저장되어, 사용자가 다시 해당 웹 사이트를 방문할 때 서버에 쿠키와 함께 전송

6) 서버는 사용자의 로그인 상태를 세션을 통해 관리

7) 세션에는 사용자의 로그인 정보 및 다양한 상태 정보가 저장

8) 세션은 서버 측에 안전히 관리되며, 브라우저는 세션 ID만을 가짐

9) 사용자가 웹 페이지에서 다른 페이지로 이동 시, 브라우저는 Request(요청) Header에 쿠키를 담아 서버에 전송

10) 서버는 받은 쿠키를 통해 세션ID를 확인하고, 해당 세션에 저장된 정보를 사용해 사용자를 인증

11) 사용자가 로그아웃을 요청하면, 서버는 세션을 만료시키고 관련된 쿠키를 무효화 시킴

12) 사용자는 브라우저에 저장된 쿠키를 삭제하거나, 쿠키 만료 기간이 지나면 자동으로 로그아웃 상태로 전환

 

 4️⃣ Session 기반 인증의 특징

🔵 장점

Session ID 자체에는 유의미한 개인정보를 담고 있지 않고, 서버에서 정보를 관리하기 때문에 데이터 손상 우려에 대해 상대적으로 안전합니다. 또한 서버에서 상태를 유지하고 있어, 사용자의 로그인 여부 확인이 쉬우며, 경우에 따라 강제 로그아웃 등의 제재가 가능합니다. 

 

🔴 단점

서버에서 모든 사용자의 상태를 관리해야 하므로 사용자의 수가 증가할수록 서버에 가해지는 부하가 증가합니다. 또한 사용자가 증가해 서버의 Scale Out을 해야 할 경우 Session의 관리가 어렵습니다. 모바일 기기, 브라우저에 공동 사용 시 중복 로그인 처리가 되지 않는 문제 등 신경 써야할 부분들이 증가합니다. 

 

 

2. Token에 대해서 

1️⃣ Token이란? 

Token은 주로 인증(Authentication)이나 권한 부여(Authorization)를 위해 사용되는 작은 데이터 조각을 나타냅니다. 웹 개발 및 보안에 토큰은 사용자나 서비스의 신원을 확인하고 특정 리소스에 접근할 수 있는 권한을 부여하는 데 사용됩니다. 주로 JSON 형식으로 표현되며, 서버에 클라이언트로 전송되어 저장하거나 HTTP 요청 헤더에 포함됩니다. 일반적으로 의미를 알 수 없는 임의의 문자열 형태로 사용자에게 발급하며 제한된 리소스에 대한 접근 권한을 캡슐화할 뿐 아니라 접근할 수 있는 리소스의 범위와 접근 가능한 기간을 통제할 수 있습니다. 

 

2️⃣ Token을 사용한 인증 Flow

1) 사용자가 로그인을 하기 위해 인증 정보를 가지고 인증 과정을 요청

2) 인증 완료 시 서버의 메모리에 Session을 저장하는 대신 사용자의 식별 정보를 가진 Token을 발급

3) 발급한 Token은 Response의 Body에 담아 사용자에게 전달

4) 사용자는 발급된 Token을 Local Storage에 저장

5) 사용자는 Request를 할 때마다 저장된 Token을 Header에 포함시켜 서버로 전송

6) 서버는 사용자로부터 전달받은 Header의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가

 

3️⃣ Token 기반 인증 특징

🔵 장점

1) Token을 사용자 측에 저장해 서버 메모리나 DB등에 부담이 없음

2) 사용자의 상태 정보를 서버에 관리하지 않아 서버의 Scale Out에 용이

3) 모바일과 브라우저의 멀티 환경에 사용이 용이

4) Token 만료 시간을 짧게 설정해 안정성을 높일 수 있음

5) CORS 방식을 사용하기 용이 

 

🔴 단점

1) 서버에 사용자 상태를 저장하고 있지 않아 사용자의 로그인 여부 확인, 경우에 따라 강제 로그아웃 등 제재를 가하기 어려움

2) 사용자가 임의로 토큰을 수정하거나 구조를 변경하게 되면 서버에서 확인이 어려움

3) Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session ID의 길이보다 길어져 HTTP Request 전송 데이터의 크기가 증가 

4) XSS 공격(크로스 사이트 스크립팅: 악의적인 사용자가 제 3자에게 악성 스크립트를 삽입해 실행되도록 하는 공격)에 취약해 Payload에 민감한 정보를 포함하는 경우 위험

 

4️⃣ Token based Authentication의 이점

1) Stateless 

Session 방식처럼 상태 정보를 서버 측이 아닌 사용자 측에서 관리해 서버의 상태를 Stateless 하게 유지가 가능.

따라서, 서버 측에서는 사용자로부터 받은 Request만을 가지고 작업을 수행할 수 있음

 

2) Scalability 

서버 상태를 Stateless하게 유지하는 것은 사용자와 서버 사이에 관계가 없다는 의미로, 일반적으로 Session 기반 인증에서는 로그인 상태 유지를 위해 최초 로그인 시 Request 한 서버로 계속 Session ID를 보내주어야 한다. 하지만 Token 기반 인증 방식은 이런 관계가 존재하지 않아 서비스 운영 중인 어떤 서버로든지 Request를 보낼 수 없음. 덕분에 Token기반 인증 방식을 사용하면 서버 확장에 유리.

 

3) Security

클라이언트가 서버로 요청 시 더 이상 Cookie를 전달하지 않아, CSRF공격(크로스 사이트 요청 위조: 인증된 사용자의 권한을 이용해 악의적인 사용자가 원치 않는 특정 동작을 수행하도록 유도하는 공격)을 방지하는데 도움이 됨. 하지만 토큰 환경의 취약점이 존재할 수 있어 미리 대비해야 한다. 

 

4) Extensibility 

Token 기반 인증 시스템에 토큰을 통해 권한 범위 지정 가능. 이를 이용해 카카오, 구글 등 소셜 계정을 이용해 다른 웹서비스에서도 로그인이 가능

 

5) Multiple Devices And Domains 

서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있음. 애플리케이션과 서비스의 규모가 커져 여러 기기들을 호환시키고 더 많은 종료의 서비스를 제공하면서 토근을 사용하면 어떤 기기, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후 요청을 처리할 수 있음.