쿠키(Cookie), 세션(Session), 토큰(Token). 이 세 가지에 대해 많이 헷갈려하는데 이를 이해하기 위해서는 웹브라우저가 서버랑 소통하는 방식을 먼저 알아야 한다.

1. HTTP / 클라이언트 - 서버 방식

일반적으로 휴대폰, 컴퓨터 등 단말기에서 필요한 데이터는 서버에 요청하여 받아온다. 즉 대부분의 데이터 전송은 HTTP와 클라이언트 - 서버 방식으로 이루어진다고 보면 된다.

• HTTP(Hyper Text Transfer Protocol) : 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜
• 클라이언트 - 서버 모델 : 리소스를 사용하는 앱(클라이언트)과 리소스가 존재하는 곳(서버)을 분리시키는 모델

HTTP 프로토콜 및 클라이언트-서버 모델로 데이터를 주고받기 위해서는 사진과 같이 요청(Request)을 보내고 응답(Response)을 받아야 한다.

이후에 살펴볼 쿠키(Cookie)가 등장한 이유는 아래와 같은 HTTP의 특성 때문이다.

HTTP의 특징

• Stateless(상태 미유지)
  -> HTTP 통신에서 서버는 클라이언트의 상태를 저장하지 않는다.
  (서버와 클라이언트 정보 공유에 대한 비용을 최소화)
• Connectionless(비연결성)
  -> 연결을 유지하지 않는 것을 기본 동작으로 가진다.

즉 서버는 클라이언트에게 응답을 완료한 이후 연결을 유지하지 않기 때문에 사용자를 기억하지 못한다.

2. 쿠키(Cookie)

이러한 HTTP 비연결성의 대안은 모든 요청에마다 "사용자 정보"를 포함해서 보내면 된다. 이 "사용자 정보"에 해당하는 것이 "쿠키"다

즉 쿠키는 쉽게 말해 브라우저에 저장되는 작은 텍스트 조각으로 사용자가 갖고 있는 정보다.
(클라이언트 측에서 보관)

• 쿠키(Cookie) : 하이퍼 텍스트의 기록서(HTTP)의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일

최초 서버에 클라이언트가 요청을 할 때 서버에서 쿠키를 생성하고 응답과 더불어 쿠키를 전달하면 클라이언트 측에서 해당 쿠키를 저장한다. 이후 요청부터 쿠키를 담아서 서버로 보낸다.

사용자(클라이언트)는 쿠키를 확인하고 수정, 삭제할 수 있다. 다만 쿠키는 당사자뿐만 아니라 제 3자가 조회하는 것도 가능하기에 개인 정보를 담은 내용이나 보안상 민감한 정보를 저장하는 데에는 부적합하다. 따라서 혹여 남에게 탈취되거나 사용자에 의해 조작되어도 크게 문제되지 않을 정보를 브라우저에 저장함으로써 웹사이트 이용을 편리하게 해 주는 것이 쿠키다.

3. 세션(Session)

서버는 아이디와 비밀번호를 입력해 로그인에 성공한 사용자(클라이언트)와 그 이후 마이페이지 버튼을 누른 사용자(클라이언트)가 동일 인물임을 알 지 못한다. 그래서 사용자가 사이트에 로그인한 상태라는 점을 서버에 인증하지 못하면 요청을 할 때 마다 반복해서 아이디와 비밀번호를 서버에 제공해야 한다. 이런 번거로움을 해결하기 위해 사용하는 것이 바로 세션(Session)이다.

• 세션(Session) : 두 지점 사이에 활성화 된 연결. 서버와 클라이언트의 연결이 활성화된 상태.

물론 쿠키에 정보를 담아 클라이언트 로그인 상태를 유지시킬 수 있지만, 제 3자도 쿠키를 조회할 수 있기 때문에 유출 및 조작 당할 위험이 존재한다. 이런 쿠키의 보안 취약점을 개선하기 위해서도 등장한게 세션(Session)이다.

[작동방식]

• 클라이언트(사용자)가 서버에 올바른 아이디와 비밀번호로 로그인에 성공하면 서버는 세션 아이디(Session ID)라는 데이터를 만든다.

• 서버는 클라이언트(사용자)에게 세션 아이디(Session ID)를 발급하며 클라이언트는 서버로부터 받은 세션 아이디(Session ID)를 쿠키에 저장한 다음 앞으로의 모든 요청에 함께 전달한다.

세션은 쿠키를 기반으로 하지만 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 저장하고 관리한다.
(세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함)

물론 이러한 세션(Session)도 서버에서 세션 아이디(Session ID)를 모두 관리하다 보니 서버의 부하가 크다는 단점이 있다.

• ex) 서버가 처리할 수 있는 사용자가 200명이라고 했을때 동시에 500명~1,000명등의 요청이 들어오게되면 서버가 터진다.

4. 토큰(Token)

서버 과부하를 일으킬 수 있는 세션(Session)의 대안은 토큰(Token)이다.

• 토큰(Token) : 인증을 위해 사용되는 암호화된 문자열

토큰 방식은 서버나 DB에 저장하지 않고도(과부하 X) 로그인했다는 정보를 비교하는 과정을 처리할 수 있다.

대표적으로 JWT(JSON Web Token)방식을 사용하는데 작동방식은 다음과 같다.

• JWT(JSON Web Token) : JSON 웹 토큰은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준

[작동방식]

• 사용자가 인증에 성공하면 서버는 암호화(Encryption) 된 토큰(Token)을 생성해서 클라이언트(Client)에게 발급한다.
  (발급된 토큰은 세션과 마찬가지로 이후 사용자가 보내는 요청에 포함된다)

• 사용자가 요청시 요청을 받은 서버는 토큰(Token)을 복호화(Decryption)하고 그것이 유효한 지를 확인만 한다.
  (서버나 DB에 토큰을 따로 저장하지 않음. 사용자 로그인 정보는 Token에 암호화됨)
  (HTTP 통신의 Stateless 한 성격과 더 적합한 인증 방식이다)

물론 토큰(Token) 방식이 무조건 세션(Session) 방식보다 좋은 건 아니다.

• 세션/쿠키의 경우 만일 악의적으로 이용된다면, 해당하는 세션을 지워버리면 된다.
  ex) 악의적 회원 Session ID를 지워서 로그인을 못하게 하는 등)
• 하지만 JWT는 한번 발급되면 유효기간이 완료될 때까지 계속 사용이 가능하다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 제재를 가하기가 어렵다.

따라서 쿠키&세션, 토큰은 경우에 맞게 사용해야 된다.