세션, 쿠키, 토큰이란?

28번째로 포스팅하게 될 내용은 세션, 쿠키, 토큰에 관한 내용입니다.

 

[ 세션, 쿠키, 토큰 등장 이유 ]

HTTP 통신은 요청 -> 응답이 종료되면 stateless한 특징 때문에 연결을 끊는 처리 방식
이러한 문제를 해결하기 위해 생김
로그인과 같은 일을 할 때, '누가' 로그인 중인지 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용

1. Connectionless 프로토콜(비연결 지향)
   클라이언트가 서버에 요청을 했을 때, 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식이다.
2. Stateless 프로토콜(상태정보 유지 안함)
   클라이언트의 상태 정보를 가지지않는 서버 처리 방식이다. 클라이언트와 첫번재 통신에 데이터를 주고 받았다 해도, 두버재 통신에 이전 데이터를 유지하지않는다

 

 

[ 쿠키 ]

• HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일
• 상태정보를 유지하는 기술
• HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가필요시 정보를 참조하거나 재사용할 수 있음

 

 

[ 쿠키 사용이유 ]

HTTP의 특징 때문에 사용자의 정보를 저장할 수 없기 때문에 웹사이트는 사용자를 구별할 수 없고 사용자는 매번 번거로운 인증 절차를 진행해야 했었음
쿠키는 간단한 사용자의 정보를 기억할 수 있는 수단이며 이것은 HTTP의 단점을 해결

 

 

[ 쿠키 특징 ]

1.  이름, 값, 만료일(저장 기간 설정), 경로 정보로 구성되어 있다.
2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
4. 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.
5. 세션보다 빠르지만 보안은 좋지 않다
6. 쿠키의 정보는 항상 최소한의 정보만을 사용하여 서버에 전송

 

 

[ 쿠키 동작 순서 ]

1. 클라이언트가 페이지를 요청
2. 웹 서버는 Set-Cookile를 통해 user='''' 이라는 쿠키를 생성
3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려줌
4. 넘겨 받은 쿠키는 클라이언트가 가지고 있다가 다시 서버에 요청할 때 요청과 함께 쿠키를 전송
5. 동일 사이트 재방문시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송

 

 

[ 쿠키의 장점 ]

• 사용자의 정보를 방문시에 저장하고 있기 때문에 방문시마다 확인해야할 번거로운 작업들을 편리하게 처리할 수 있음
• 사용자마다 저장하는 정보가 다르기 때문에 사용자에 맞게 웹사이트의 모드나 언어등을 설정할 수 있음
• 운영자 입장에선 사용자가 저장한 쿠키 정보를 이용하여 사용자의 행동과 패턴을 분석하고 트래킹 할 수 있음

 

 

[ 쿠키의 단점 ]

• 쿠키는 사용자 인증, 검색 기록 등의 개인 정보를 저장하는 것이기 때문에 사용자의 개인 정보를 침해 당할 수 있음
• 이것은 사용자 로컬에 저장되는 것이기 때문에 쉽게 조작되거나 가로챌 수 있어 보안이 취약함

 

 

[ 쿠키 생명주기 ]

• 쿠키는 자원이기 때문에 무제한으로 살려두지 않음
  • 세션 쿠키 : Set-Cookie때, 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
  • 영속 쿠키 : Set-Cookie때, 만료 날짜를 입력하면 해당 날짜까지 유지

 

 

[ 세션 ]

• 세션이란 일정 시간동안 같은 사용자로 부터 들어오는일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
• 방문자의 요청에 따른 정보를 방문자 메모리에 저장하는 것이 아닌 웹 서버가 세션 아이디 파일을 만들어 서비스가 돌아가고 있는 서버에 저장을 하는것을 말함
• 프로세스들 사이에서 통신을 하기 위해 메시지 교환을 통해 서로를 인식한 이후부터 통신을 마칠 때까지의 기간동안 서버에 잠시 방문자 정보를 저장하는 것

 

 

[ 세션 특징 ]

• 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션 id를 부여, 세션 스토리지에 세션 정보를 저장
• 클라이언트는 이 세션id를 쿠키를 통해 기억
• 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 cookie에 세션 id를 담아서 전송
• 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단
  • 세션과 쿠키는 완전히 분리된 개념이 아님
• 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리할 수 도 있음

 

 

[ 세션 동작 순서 ]

1. 사용자 로그인 요청
2. 서버에서 계정 정보를 읽어 사용자를 확인 하고, 사용자의 고유한 ID를 부여하여 세션 저장소에 저장한 후, 이와 연결된 세션ID를 발급
3. 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냄
4. 서버는 쿠키를 받아 세션 저장소에서 대조 후 대응되는 정보를 가져옴
5. 인증이 완료 되고 서버는 사용자에 맞는 데이터를 보내줌

 

 

[ 세션 장점 ]

1. 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거침. 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 보면 된다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고있지 않다(중요 정보는 서버 세션에)
2. 사용자 A는 1번, 사용자 B는 2번 이런식으로 고유의 ID값을 발급받게 된다. 그렇게 되면 서버에서는 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있어 서버의 자원에 접근하기 용이할 것

 

 

[ 토큰 ]

사용자 인증을 위해 사용되는 암호화된 문자열

 

[ 토큰 특징 ]

• 사용자에 대한 정보를 암호화해서 브라우저에 저장하고, 웹페이지 접속시, 저장된 정보를 가져와 사용자마다 다른 화면을 보여주는 용도로 사용할 수 있음
• 앱이 서버에 토큰 전송, 서버가 이 토큰을 사용해 토큰 값 응답
• 토큰은 제한된 수명을 가지고 있어서, 토큰이 한 번 만료되면 새로 생성되어야 함

 

[ JWT ]

• 인증에 필요한 정보들을 암호화시킨 토큰을 의미
• 션/쿠키 방식과 유사하게 사용자는 Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송

 

 

[ 토큰 작동방식 ]

1. 사용자가 서버에 로그인 함
2. 서버가 로그인 정보를 받아서 토큰을 만듬
3. 사용자는 브라우저에서 토큰을 받아 임시저장힘
4. 사용자가 토큰과 함께 서버에 요청을 보냄
5. 서버는 자신이 만든 토큰이 맞는지 확인하고, 토큰이 맞는 경우에만 올바른 응답을 보내줌

 

[ 토큰의 구조 ]

Header

• JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64 URL-Safe 인코딩된 문자열
• 헤더는 jwt를 어떻게 검증하는가에 대한 내용을 담고 있음
• alg는 서명시 사용하는 알고리즘이고, kid는 서명시 사용하는 키를 식별하는 값

 

Payload

• JWT의 내용
• 페이로드에 있는 속성들을 클레임 셋이라고 부름
• 클레임 셋은 jwt에 대한 내용(토큰 생성자의 정보, 생성일시 등)이나 클라이언트와 서버 간 주고받기로 한 데이터들로 구성

 

Signature

• 점(.)을 구분자로 해서 헤더와 페이로드를 합진 문자열을 서명한 값
• 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 생성하고 Base64 URL-Safe로 인코딩

 

[ 토큰 장점 ]

• header와 payload 를 가지고 signaure를 생성하므로 데이터 위변조를 막을 수 있음
• 인증 정보에 대한 별도의 저장소가 필요없음
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증 되었다는 서명 등 필요한 모든 정보를 자체적으로 지님
• 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능
• 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능해 확장성이 뛰어남

 

 

[ 토큰단점 ]

• 쿠키나 세션과 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해짐
• payload 자제는 암호화되지 않기 땨문에 유저의 중요한 정보를 담으면 안됨
• 토큰을 탈취당하면 대처하기 어려움
• 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제 할 수 있음

•