Cookie, Session, Token

먼저, Cookie, Session, Token에 대해서 설명하기에 앞서 HTTP 프로토콜 특징에 대해서 알아야 할 필요가 있습니다.

HTTP 프로토콜은 요청에 따른 응답을 받으면 끊어집니다.(Connectionless), 즉, 한번 클라이언트와 서버가 서로 연결이 이뤄지고 요청 응답이 완료되었으면 연결이 끊기는데 왜냐하면 HTTP 자체가 인터넷 상에서 불특정 다수와 연결되는 통신 환경을 만들기위해 설계되었기 때문입니다.

서버가 다수의 클라이언트와 연결이 끊기지 않고 계속 연결되어 있으면, 연결 유지를 위한 리소스가 너무 많이 필요하게 되어, 서버 관리 측면에 있어서는 단점으로 작용하기 때문입니다.

그리고 HTTP 프로토콜은 통신이 종료되면 어떠한 상태 정보도 남지 않습니다.(Stateless)

따라서, 로그인하고 다른 웹페이지로 접근 시, 로그인 상태가 유지되지 않아 계속 중복되는 과정을 거쳐야할 수 있게 됩니다.

이러한 불필요한 작업을 제거하기 위해 쿠키(Cookie)가 등장하였습니다.

📌 쿠키(Cookie)

쿠키는 웹사이트에 접속할 때, 서버쪽에서 웹 브라우저(클라이언트) 메모리에 정보를 기록하는 key-value 쌍의 데이터 파일입니다.

즉, 웹 브라우저(클라이언트)는 이러한 데이터 파일들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다.

쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다.

쿠키는 항상 고정된 값을 가지진 않고, 사용자가 웹 사이트를 접근할 때마다 수시로 정보가 바뀝니다.

💡 쿠키(Cookie) 구성 요소

• Name : 쿠키의 이름
• Value : 쿠키에 저장된 값
• Expires : 쿠키가 언제 삭제되는지 만료일을 설정
• Domain : 쿠키가 사용되는 도메인을 지정. 이 값이 현재 탐색 중인 도메인과 일치하지 않을 경우, "타사 쿠키"로 간주되어 브라우저에서 거부. 이렇게 해서 한 도메인에서 다른 도메인에 대한 쿠키를 사용하지 못하게 설정
• Path : 쿠키가 반환할 경로 설정
• Secure : 보안 연결 설정
• HttpOnly : HTTP외에 다른 통신 사용 가능 설정

💡 쿠키(Cookie) 종류

쿠키이름	특징
Session Cookie	보통 만료시간(Expire date)를 설정하고 메모리에만 저장되며 브라우저 종료시 쿠키를 삭제
Persistent Cookie	장기간 유지되는 쿠키, 파일로 저장되어 브라우저 종료와 관계없이 사용
Secure Cookie	HTTPS에서만 사용, 쿠키 정보가 암호화되어 전송
Third-party Cookie	방문한 도메인과 다른 도메인의 쿠키 보통 광고 베너 등을 관리할 때 유입 경로를 추적하기 위해 사용

💡 쿠키(Cookie) 동작 방식

1. 클라이언트가 페이지를 요청
2. 서버에서 쿠키를 생성하고 HTTP 헤더에 쿠키를 포함하여 응답하며, 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관
3. 같은 요청을 할 경우, HTTP 헤더에 쿠키를 함께 요청
4.서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때, 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

💡 쿠키(Cookie) 단점

• 쿠키에 대한 정보를 매번 헤더에 추가시켜 보내기 때문에 상당한 트래픽을 발생시킵니다.

• 쿠키같은 경우는 브라우저에 정보가 저장되기 때문에, 쿠키가 유출되면 보안 문제가 발생합니다.

📌 세션(Session)

세션은 쿠키의 단점을 보완하여 등장하였습니다.

세션은 쿠키를 기반으로 하고 있습니다.

데이터 파일을 브라우저에 저장하는 쿠키(Cookie)와 달리 세션(Session)은 서버 측에서 관리합니다.

💡 세션(Session)의 동작 방식

1. 클라이언트가 서버에 접속 시 Session ID를 발급 받습니다.

2. 클라이언트는 Session ID에 대해 쿠키를 사용해서 저장하고 가지고 있습니다.

3. 클라이언트는 서버에 요청할 때, 이 쿠키의 Session ID를 같이 서버에 전달해서 요청합니다.

4. 서버는 Session ID를 전달 받아서 별다른 작업없이 Session ID로 세션에 있는 클라이언트 정보를 가져와서 사용합니다.

5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답합니다.

세션은 각 클라이언트에게 고유 ID를 부여하고 Session ID로 클라이언트를 구분해서 클라이언트의 요구에 맞는 서비스를 제공합니다. 그리고 보안 면에서는 쿠키보다 우수합니다.

💡 세션(Session)의 단점

• 클라이언트의 수가 많아지면 서버에 저장해야할 Session 또한 많아지기 때문에 서버의 과부하를 일으킬 수 있습니다.

• 서버가 여러대 일 경우, 한 개의 클라이언트를 위한 세션 정보를 다른 서버들이 모두 가지고 있어야 서버를 분산해서 운영할 때도, 클라이언트에 대한 인증 절차가 가능해집니다. 그렇기 때문에 성능 저하의 요인이 됩니다.

📌 토큰(Token)

토큰은 보호해야될 데이터들을 토큰으로 치환하여 원본 데이터 대신 토큰을 기반으로 서버 클라이언트간 인증을 진행하는 방식입니다.

즉, 인증을 위해 사용되는 암호화된 문자열이라 할 수 있다.

이러한 토큰 기반의 인증 방식은 상태를 유지하지 않는 Stateless입니다.

💡 토큰(Token)의 동작 방식

1. 클라이언트가 서버에게 로그인 요청을 보냅니다.

2. 서버는 클라이언트의 정보를 검증한 후, 사인된(signed) 토큰을 생성해서 응답합니다. 여기서 signed는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있습니다.

3. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청할 때마다 해당 토큰을 함께 서버에 전달합니다.

4. 서버는 토큰을 검증 후, 이에 대한 응답을 합니다.

이러한 토큰 기반의 인증은 쿠키(Cookie)의 단점인 보안 문제와 세션(Session)의 단점인 서버 분산 관리 시 모든 서버가 클라이언트의 정보를 각각 모두 가져야 한다는 점을 모두 해결해 줄 수 있습니다.

인증 토큰 값 하나만 있으면 관련 모든 서버에서 인증되며, 브라우저에 직접 저장하는 방식도 아니어서 보안상의 큰 이점을 갖습니다.

또한 가장 큰 장점은 무상태(Stateless)이며, 확장성(Scalability)이 있다는 점입니다.

토큰은 클라이언트 측에 저장하기 때문에 완전히 Stateless하며, 서버를 확장하기에 매우 적합한 환경을 제공합니다.

대표적인 토큰 기반의 인증 방식은 JWT(Json Web Token)이 있습니다.

이상으로 Cookie, Session, Token에 대해서 간단히 알아봤습니다.

참고

• https://sdy-study.tistory.com/44
  (Cookie, Session, Token 이란?)

• https://interconnection.tistory.com/74
  (쿠키와 세션 개념)