고수만/서버

쿠키(Cookie), 세션(Session), 토큰(Token) 의 차이점 - 쉬움

JumBack2 2024. 11. 16. 17:40

 

해당 내용은 내려갈수록 점점 어려운 내용을 언급하겠다. 처음이 쉬운 사람은 쭉 내려도 무방하다.

 

일단 쿠키에 대해 알기 앞서 알아야 할 중요 개념들이 있다.

 

1.브라우저

2.클라이언트와 서버

3.HTTP

4.RestAPI

 

브라우저(Browser)란 무엇인가?

우리는 브라우저를 이미 알고 많이 사용하고 있다. 

브라우저는 인터넷을 통해 웹 페이지와 웹 애플리케이션에 접근하는 데 사용되는 소프트웨어 응용 프로그램이다. 사용자가 웹 주소(URL)를 입력하면, 브라우저는 해당 주소의 서버에 요청을 보내고, 서버로부터 받은 데이터를 해석하여 사용자의 화면에 웹 페이지를 표시한다. 브라우저의 핵심 기능과 특징은 다음과 같다:

웹 페이지 렌더링:

HTML, CSS, JavaScript 등의 웹 표준 언어를 해석하여 사용자에게 시각적으로 표현한다.
최신 웹 표준을 지원함으로써 다양한 웹사이트와 웹 애플리케이션의 호환성을 보장한다.

웹 사용자에게 어플리케이션을 표준적으로 보여주는 역할을 하는 것이다.

 

탐색 및 상호작용:

 

URL을 통해 웹 페이지를 탐색하고, 하이퍼링크를 사용하여 다른 페이지로 쉽게 이동할 수 있다.
사용자 입력, 버튼 클릭, 양식 제출 등과 같은 상호작용을 처리한다.

 

북마크 및 기록 관리:

 

자주 방문하는 사이트를 북마크하거나 방문 기록을 관리하여 사용자가 원하는 웹 페이지를 빠르게 찾을 수 있도록 한다.
플러그인과 확장 프로그램:

 

그 밖에 추가 기능을 제공하는 플러그인이나 확장 프로그램을 설치하여 브라우저의 기능을 확장할 수 있다.

HTML, CSS, JavaScript 등의 웹 표준을 준수하여, 다양한 웹 사이트와 애플리케이션을 정확하고 일관되게 표시한다.
대표적인 브라우저로는 Google Chrome, Mozilla Firefox, Safari, Microsoft Edge 등이 있다. 각 브라우저는 고유의 기능과 특성을 가지고 있으며, 사용자의 요구와 환경에 맞춰 선택할 수 있다.

 

2.클라이언트와 서버

클라이언트와 서버를 이야기하면 필자의 과거 신입 때가 떠오른다.

일본 회사에서 개발자를 시작한 필자는 갑자기 서버와 클라이언트라는 개념에 대해 의문을 가지게 된다. 

Chat Bot을 만드는 프로젝트에서 서버와 클라이언트가 계속 나오길래 선배 개발자에게 안되는 일본어로

클라이언트와 서버에 대해 질문을 한 적이 있다.

그 때 선배는 클라이언트와 서버는 역할에 따라 바뀔 수 있다고 했다. 필자는 그 때 그것이 이해가 안됬던 기억이 있다.

 

클라이언트와 서버는 인터넷과 컴퓨터 네트워킹에서 굉장히 중요한 역할을 한다. 

클라이언트는 서비스나 자원을 요청하는 시스템이다 사용자가 웹사이트에 접속하거나 앱을 사용할 때, 클라이언트는 서버에 특정 정보나 서비스를 요청한다. 이때 사용자의 요청은 클라이언트에서 발생하여 서버로 전달된다.

반면, 서버는 이러한 요청을 받아들이고 처리하는 시스템이다. 서버는 데이터베이스 접근, 파일 전송, 이메일 전송, 웹 페이지 제공과 같은 서비스를 제공한다. 서버는 클라이언트로부터의 요청을 처리하고, 필요한 데이터나 결과를 다시 클라이언트에게 전송한다. 이 과정에서 서버는 여러 클라이언트의 요청을 동시에 처리할 수 있어야 한다.

 

그림을 그리자면 대략 이렇게 그려질 것이다.

아래 그림에서 호출하는 클라이언트와 응답하는 서버다.

이렇게만 보면 모니터가 클라이언트고 본체가 서버인 것 같은 느낌이 든다.

왜냐하면 브라우저는 모니터에 있고 항상 요청을 하는쪽이니까!

하지만 모니터는 단순 출력 기기에 불과하다.

 

 

 

만약 아래와 같이 3개의 컴퓨터가 있다면 어떤게 클라이언트고 서버인가??

 

 

 

 

어느쪽이든 클라이언트가 될 수 있고 서버가 될 수 있다. 내 컴퓨터에서 다른 컴퓨터에 요청을 보내면 내 pc가

클라이언트가 되는 것이고 그 응답을 주는 pc가 서버가 되는 것이다. 

 

주로 일반 컴퓨터를 사용하는 사용자 입장에서는 요청하는 것만 주로하니 클라이언트라고 생각하겠지만

만약 내 pc에서 웹서버를 띄우고 다른 사람에서 응답을 제공하면 내가 서버 pc가 될수도 있는 것이다!

 

즉 역할에 따라 호출은 클라이언트 응답은 서버 라고 생각하자. 

 

3.HTTP
https://dog-foot-sleep.tistory.com/38 를 보고 오면 될 것 같다.

 

HTTP와 HTTPS의 차이점??

일단 우리는 HTTP라는 말을 너무도 많이 들어봤다. HTTP는 Http: HyperTexT Protocol의 약자이다. 이것도 결국 프로토콜이라는 것인데 하이퍼텍스트를 빠르게 교환하기 위한 프로토콜이다. 그럼 하이퍼텍

dog-foot-sleep.tistory.com

 

4. Restful API

RESTful API는 Representational State Transfer (REST) 원칙에 기반한 애플리케이션 프로그래밍 인터페이스(API)이다. REST는 2000년에 로이 필딩(Roy Fielding)에 의해 소개된 아키텍처 스타일로, 웹 서비스 개발에 널리 사용된다.

RESTful API의 주요 특징은 다음과 같다:

자원 기반의 구조 (Resource-Based): RESTful API에서 "자원"은 데이터나 서비스를 의미한다. 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별된다.

무상태성 (Stateless): 서버는 클라이언트의 상태를 저장하지 않는다. 각 요청은 독립적이며 필요한 모든 정보를 포함해야 한다. 이는 서버의 처리를 단순화하고 확장성을 높힌다.

메소드를 통한 작업 (Method-Based Operations): RESTful API는 표준 HTTP 메소드를 사용하여 자원을 처리한다. 예를 들어, GET(조회), POST(생성), PUT(업데이트), DELETE(삭제) 등이 있다.

일관된 인터페이스 (Uniform Interface): REST API는 일관된 인터페이스를 제공하여 상호작용의 단순화와 이해도를 높인다.

여기서 말하는 인터페이스는 단순하게 생각해서 규격이다. 여러분들이 콘센트를 사용할 때 220v를 규격으로 사용해서 

전자기기에 연결해 사용하듯 모두가 사용 할 수 있는 표준 규격을 만드는 것이 인터페이스이다.

 

위 설명된 특징을 가진 규격을 만들어 HTTP 통신방법으로 자원을 주고 받으려고 만든 것이다.

 

자 그럼 기본 지식은 설명이 끝났다!

 

 

쿠키의 등장 배경

 

쿠키는 웹사이트와 사용자의 브라우저 사이에서 정보를 저장하고 교환하기 위한 작은 데이터 조각이다.

그리고 그 정보를 브라우저에 저장하는 것이 바로 쿠키이다.

 

그런데 왜 정보를 저장해야 될까? 그 이유는 웹은 바로 HTTP를 기반으로 통신하고 HTTP가 비연결식 기반 통신을

하기 때문이다.이는 무상태성(stateless) 와 연관되는데, 쉽게 말해 HTTP 통신은 요청을 한 후 연결이 종료되기에 상태를 저장하지 않는다. 그래서 클라이언트 측에서나 서버 측에서 특별한 무언가를 하고 싶다면 상태를 저장해야 되는 것이다.

(여기서 질문이 생겨야 된다. 연결 후 종료를 하는데 어떻게 서버의 응답인걸 알지??? 잘 생각해보길 바란다.)

 

예를 들어 누군가 로그인을 했을 때 로그인 중인지 상태를 기억하려면 어딘가엔 저장을 해야 된다는 것이다. 그렇지

않으면 새로고침 할 때마다 로그인을 해야하는 참사가...

 

웹 서버가 사용자의 웹 브라우저에 전송하는 이 데이터는 사용자의 컴퓨터에 저장되며, 이후 동일한 서버에 다시 접속할 때 브라우저가 이 쿠키 정보를 서버에 전송한다. 이 과정을 통해 서버는 사용자를 식별하고, 사용자의 이전 활동이나 설정을 기억한다.

쿠키의 주요 기능은 다음과 같다

  • 세션 관리: 사용자의 로그인, 쇼핑 카트, 게임 점수 등의 정보를 저장한다.
  • 개인화: 사용자의 선호도, 테마 설정 등을 기억하여 개인화된 서비스를 제공한다.
  • 트래킹: 사용자의 방문 및 활동 기록을 추적하여 광고나 분석 목적으로 활용한다.

쿠키는 크게 두 종류로 나뉜다:

  • 세션 쿠키: 브라우저가 열려 있는 동안만 유효하며, 브라우저가 닫히면 사라진다.
  • 영속적 쿠키: 설정된 만료 날짜까지 브라우저에 저장되며, 이를 통해 장기간 사용자를 식별할 수 있다.

 

쿠키 사용의 장점에도 불구하고, 몇 가지 단점도 존재한다:

보안 문제: 쿠키는 보안에 취약할 수 있어, 중요한 정보는 암호화하여 저장해야 한다.
개인 정보 보호: 사용자의 동의 없이 쿠키를 이용해 트래킹하는 것은 개인 정보 보호와 관련된 이슈를 야기할 수 있다.

이렇게 서버와의 정보 교환에서 저장하고 싶은 내용을 저장하는 것이 쿠키이고 브라우저에 저장하면 되는데

왜 굳이 세션이 나오게 되었는가?

 

세션의 등장 배경

 

 

 

기본 간단한 정보는 클라이언트에 저장하여도 큰 문제가 안되었다. 그러나 로그인를 예로 들어 생각해보자.

로그인에는 ID와 비밀번호가 들어가는데 우리는 매번 새로고침이나 화면이동 때마다 로그인을 하길 바라지 않는다.

그래서 쿠키에 저장하였다. ID와 비밀번호 정보를 서버가 쿠키로 클라이언트에 줘 저장하면 어떻게 될까?

 

클라이언트는 우리 pc에 있고 지금도 여러분은 F12를 누르면 관리자 모드로 해당 pc의 쿠키를 열어볼 수 있다.

그렇게 비밀번호가 털리는 것이다.

 

세션은 웹에서 사용자의 상태를 서버 측에서 유지하는 기술이다. 웹은 기본적으로 HTTP 프로토콜을 사용하는데, 이는 무상태(stateless) 특성을 가지고 있어서, 한 번의 요청과 응답이 끝나면 연결이 종료되고 서버는 클라이언트(사용자)에 대한 정보를 유지하지 않는다. 이러한 특성 때문에, 사용자가 로그인하고 다른 페이지로 이동해도 계속 로그인 상태를 유지할 수 있는 방법이 필요하다. 여기서 세션이 중요한 역할을 한다. 쿠키에 저장하면 클라이언트에서 조작하기도 털리기도 쉽다.

 

따라서 중요 내용을 서버측에서 저장하고 관리하는 것이다.


세션은 사용자가 웹사이트에 로그인하거나 특정 작업을 수행할 때 서버에 의해 생성된다. 서버는 각 사용자를 식별할 수 있는 고유한 세션 ID를 생성하고, 이 ID는 사용자의 브라우저에 쿠키 형태로 저장된다. 사용자가 서버에 요청을 보낼 때마다 이 세션 ID도 함께 전송되어, 서버는 세션 ID를 통해 사용자의 고유한 세션을 식별하고, 사용자별로 저장된 정보(예: 로그인 상태, 장바구니 내용, 선호 설정 등)를 참조할 수 있다.

이 방식의 장점은 사용자의 중요한 정보가 서버 측에서 관리된다는 점이다. 이는 사용자의 브라우저에 저장되는 쿠키에 비해 보안상 유리하다. 

하지만 클라이언트가 수천만명 이상인 네이버 같은 페이지를 생각해보자 서버가 동시에 수천만명이 들어와 세션 데이터를 요청하고 응답을 원한다면 아마 엄청난 부하가 생길 것이고 오로지 서버에서 모두 감당해야 될 것이다.

서버의 메모리에 사용자의 정보를 저장해야 하기 때문에, 많은 사용자를 관리해야 하는 경우 서버에 부하가 될 수 있다. 또한, 세션을 서버에서 관리하므로, 서버가 다운되면 해당 세션 정보도 함께 손실될 수 있다. 이러한 문제를 해결하기 위해 분산 세션 관리나 다른 상태 관리 기술이 개발되고 있다.

 

토큰의 등장 배경

그래서 이 모든 장점을 가지기 위해 토큰이란 걸 사용한다.

JWT는 어려운 것이 아니라 그 토큰들 중 모두가 사용할 수 있도록 표준이 될만한 토큰을 만든 것이다.

 

토큰은 인증과 인가 과정에서 사용자의 신분이나 권한을 증명하는 데 사용되는 디지털 자격증명이다. 

 

인증 (Authentication):

의미: 인증은 사용자가 누구인지 확인하는 과정이다. 즉, 사용자가 자신이 주장하는 사람이 맞는지를 검증하는 것이다.
예시: 로그인 과정에서 사용자 이름과 비밀번호를 입력하면, 시스템은 이 정보를 검증하여 해당 사용자가 맞는지 확인한다.

 

인가 (Authorization):

의미: 인가는 인증된 사용자가 수행할 수 있는 작업의 범위를 결정하는 과정이다. 즉, 사용자가 시스템 내에서 어떤 자원에 접근하거나 어떤 작업을 수행할 수 있는지를 정하는 것이다. Authorization은 간단히 말해 인증을 어느 범위 까지 권한을 줄 것인가를 정해주는 것이다. 


예시: 카트라이더를 할 때 방장과 참여자는 화면의 구성이 조금 다르다. 권한이 다르기 때문이다. 방장은 강퇴를 할 수 있는

권한이 존재하기 때문이다. 같은 접속 인증을 했지만 권한이 다르다.

 

웹 환경에서 토큰은 사용자가 로그인을 한 후 서버로부터 발급받아, 이후의 요청에서 이 토큰을 사용하여 자신의 신원을 인증하고 자원에 접근할 수 있게 한다. 토큰은 사용자의 정보를 서버가 아닌 클라이언트 측에서 보유하며, 서버는 요청을 받을 때마다 토큰을 검증하여 사용자를 식별한다.

JWT(JSON Web Token)는 웹 토큰 중 하나로, 인증 및 정보 교환에 널리 사용된다. (여기서 JSON이 무엇인지는 인터넷에 찾아보길 바란다.) JWT는 세 부분으로 구성되어 있다: 헤더(Header), 페이로드(Payload), 그리고 서명(Signature). 헤더에는 토큰의 타입과 사용된 해시 알고리즘이 포함되어 있다. 페이로드에는 사용자에 대한 정보(예: 사용자 ID)나 토큰의 만료 시간 등이 들어 있다. 서명은 헤더와 페이로드, 그리고 서버의 비밀키를 합쳐서 생성되며, 이를 통해 토큰의 무결성과 유효성을 검증한다.

 

Header (헤더):

역할: 헤더는 토큰의 타입(JWT)과 사용된 서명 알고리즘(예: HMAC SHA256, RSA)을 선언한다.
구성: JSON 객체 형태로 이루어져 있으며, 이를 Base64Url 방식으로 인코딩하여 사용한다.
예시: {"alg": "HS256", "typ": "JWT"}

 

Payload (페이로드):

역할: 페이로드는 토큰에 포함될 클레임(claims)을 담고 있다. 클레임은 토큰 사용자에 대한 속성이나 추가 데이터를 포함한다. 주 내용이 여기에 들어간다.
종류: 등록된 클레임(예: 발급자, 주제, 수신자), 공개 클레임, 그리고 비공개 클레임이 있다.
구성: JSON 객체 형태로 이루어져 있으며, 이를 Base64Url 방식으로 인코딩하여 사용한다.
예시: {"sub": "1234567890", "name": "John Doe", "admin": true}

 

Signature (서명):

역할: 서명 부분은 토큰의 무결성과 인증을 보장한다. 서버는 헤더와 페이로드를 특정 알고리즘과 비밀 키를 사용하여 서명한다.서버 측에서 복호화를 한 후 서명에 문제가 있다면 이는 위변조 되었다고 판단할 수 있다.
생성 방법: 서명은 헤더의 인코딩된 문자열과 페이로드의 인코딩된 문자열을 합친 후, 헤더에 지정된 알고리즘과 비밀 키 혹은 공개 키를 사용하여 해싱한다.
중요성: 이 서명을 통해 토큰이 변조되지 않았음을 검증할 수 있다. 만약 토큰의 내용이 변경되면, 서명이 일치하지 않게 되어 인증에 실패한다.

 

아래는 JWT 사이트에서 암호화 된 JWT를 복호화 해준 것이다.

Encoded 된 데이터는 읽어도 이해할 수 없지만 Decoded 된 내용을 보면 각각의 데이터가 key와 value로 쌍을 이루어

저장되어 있는 것을 확인 할 수 있다.

 

장점:

  1. 분산 시스템에 적합하다: JWT는 각 서버 혹은 서비스에서 인증을 별도로 관리할 필요 없이, 토큰 자체에 모든 필요 정보를 포함하기 때문에 마이크로서비스나 분산 시스템에 적합하다.
  2. 확장성이 뛰어나다: 클라이언트와 서버 사이에 전송되는 정보량이 적어서 효율적이며, 시스템 확장 시 추가 인증 서버의 부담을 줄일 수 있다.
  3. 언어와 플랫폼 독립적이다: JWT는 JSON 형식을 사용하므로 다양한 프로그래밍 언어와 플랫폼에서 쉽게 사용할 수 있다.
  4. 보안성이 높다: 서명을 통해 데이터의 무결성을 보장하며, 필요에 따라 페이로드의 정보를 암호화할 수 있다.

 

단점:

  1. 토큰의 크기가 크다: 페이로드에 많은 정보를 담을 경우 토큰의 크기가 커져 네트워크 부하가 증가할 수 있다.
  2. 상태를 저장하지 않는다 (Stateless): JWT는 상태를 저장하지 않기 때문에 한 번 발행된 토큰은 유효 기간이 끝나기 전까지는 취소할 수 없다. 이는 보안상의 문제를 야기할 수 있다.
  3. 보안 취약점에 주의해야 한다: 서버에서 JWT의 서명을 검증하지 않거나, 암호화 알고리즘에 취약점이 있는 경우 보안 문제가 발생할 수 있다.
  4. 서버 사이드 세션 저장소가 필요 없다는 장점과 동시에 단점: 세션 기반 인증과 달리 서버에 사용자 상태를 저장하지 않기 때문에 사용자의 상태를 추적하기 어려울 수 있다.



JWT의 장점은 토큰 자체가 필요한 모든 정보를 포함하고 있어서 별도의 세션 저장소가 필요 없다는 점이다. 이로 인해 서버의 부하를 줄이고, 확장성 있는 아키텍처를 구축할 수 있다. 또한, JWT는 자가 포함(self-contained) 특성을 가지고 있어, 사용자의 상태를 서버에 저장할 필요 없이 토큰 안에 모든 필요한 정보를 담을 수 있다. 하지만 토큰이 탈취되면 보안 문제가 발생할 수 있으므로, 통신은 항상 암호화되어야 하고, 토큰의 보안 관리에도 주의를 기울여야 한다.

 

 

이렇게 쿠키에 중요 정보를 저장하면 생기는 문제를 해결하기 위해 세션을

세션의 서버 부하를 해결하기 위해 암호화 해 정보를 토큰화 하여 클라이언트에 저장시키고 인증이 필요할 때

해당 토큰을 서버가 다시 읽어 복호화 해 인증 확인을 하는 방법이

바로 토큰을 통한 인증이다.

 

 

요즘 세션과 쿠키는 어떻게 쓰이는가?

 

쿠키는 주로 사용자 설정으로 많이 사용된다.


"사용자 설정"은 쿠키를 사용하여 웹사이트에서 개별 사용자의 환경 설정이나 선호도를 저장하고 이를 바탕으로 맞춤형 사용자 경험을 제공하는 기능을 말한다. 이 과정에서 쿠키는 사용자의 브라우저에 작은 데이터 조각들을 저장하여, 사용자가 웹사이트를 다시 방문할 때 이러한 설정을 기억하고 적용한다.

이런 방식으로 사용자 설정을 저장하는 것은 다음과 같은 이점을 제공한다:

개인화된 사용자 경험: 사용자가 사이트 내에서 선호하는 언어, 테마, 레이아웃 설정 등을 기억하여, 매번 설정을 변경할 필요 없이 바로 개인화된 환경을 제공한다.

편리성: 로그인 정보, 검색 기록, 장바구니 등 사용자의 이전 활동을 기억하여 사용자가 웹사이트를 더 편리하게 이용할 수 있도록 돕는다.

맞춤형 콘텐츠: 사용자의 이전 활동과 선호에 기반하여 맞춤형 콘텐츠나 광고를 제공한다. 예를 들어, 특정 상품을 자주 검색하는 사용자에게 관련 상품을 추천할 수 있다.

효율적인 웹사이트 성능: 사용자의 선호 설정을 기억함으로써, 웹사이트 로딩 시간을 단축하고 사용자 경험을 향상시킨다.

세션은 이중 보안으로 많이 사용된다.

보안 강화된 인증: 쿠키에 비해 서버 측에서 관리되기 때문에 보안성이 높은 인증을 제공한다.
사용자 정보 저장: 로그인 세션 동안 필요한 사용자 정보를 저장하고, 사용자가 로그아웃하면 자동으로 정보를 폐기한다.

 

쿠키 설정 및 사용자 추적 방법


사용자가 웹사이트에 처음 방문하면, 그들의 브라우저에 고유한 식별자를 가진 쿠키를 생성한다. 

이 쿠키는 사용자를 식별하는 데 사용된다.사용자의 클릭, 검색어 입력, 페이지 방문과 같은 행동들을 쿠키에 기록한다. 이 정보를 통해 사용자가 웹사이트를 어떻게 사용하는지 파악한다.

 

서버는 사용자의 쿠키에서 수집한 데이터를 분석한다. 이 과정에서 사용자의 행동 패턴과 선호도를 이해하게 된다.
분석된 데이터를 기반으로 사용자에게 맞춤형 콘텐츠를 제공할 수 있다. 예를 들어, 사용자가 자주 방문하는 페이지나 관심을 보인 항목에 기반하여 추천 콘텐츠를 제공한다.

 

즉 서버 측에서 사용자의 패턴을 이해할 수 있도록 쿠키를 클라이언트에 심고 해당 내용을 쿠키에서 뽑아 서버에서 해석하여 그에 따른 서비스를 제공하는 것이다. 이 덕에 내가 오늘의 집 같은 인테리어 구매 사이트에서 '식탁' 을 한번 클릭하여

보면 구글 광고에 식탁에 관련 된 광고들이 주로 뜨게 되는 것이다.