Cookies, Session, JWT

최근 프로젝트를 하면서 JWT 를 처음 사용해봤다. 그래서 JWT 를 찾아보면서 구조, 생긴계기 등 작성을 해보려한다.

 

JWT 가 생긴 계기를 말하려다보면 HTTP , Session Cookie 를 빼놓을수가 없다.

 

먼저 HTTP 이야기부터 해야한다.

 

HTTP 란?

인터넷상에서 데이터를 주고받기 위해 서버 및 클라이언트 모델을 따르는 프로토콜이다.

 

HTTP 는 비연결성 및 무상태성의 특징이 있다. 따라서 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않습니다.

 

그래서 서버는 클라이언트를 식별할 수 없다는 단점이 존재한다. 이 점을 보완하기 위한 Cookie, Session 이란 기술이 생겨났다.

 

Cookies 란?

 

클라이언트가 어떠한 웹사이트를 방문하고 서버에서는 클라이언트 브라우저에 설치되는 정보 파일이다.

 

기본적으로 key - value 형태를 띄고 있다.

 

클라이언트가 서버에 요청할때마다 ID, PW 등을 통해 사용자의 정보를 전달한다고 생각하면 끔찍하다.

 

그래서 Cookies 가 생기고 난 후에 로그인 없이 진행할 수 있는 편의성을 제공한다.

 

쿠키의 순서

 1. 클라이언트가 서버에 요청한다.

 2. 서버는 클라이언트 측에 저장하고싶은 정보를 Cookie 에 담는다.

 3. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 담아 보낸다.

 

Cookies 단점

 

기본적으로 보안에 취약하기 때문에 ID, PW 를 탈취 당할 수 있다.

 

브라우저 별 Cookie 에 대한 지원 형태가 다르기 때문에 공유가 불가능하다.

 

 

Session 란?

 

Cookie의 문제점을 해결하기 위해 생겨난 개념이다.

 

쿠키와 제일 큰 차이점은 브라우저가 아닌 서버의 메모리에 저장한다는 점이다.

 

서버에 저장을 하기 때문에 요청이 많아지게 되면 서버 과부하가 될 수 있다.

 

그리고 쿠키에 비해서는 보안이 낫지만 이마저도 좋지는 않다. Session ID 자체를 탈취하여 다른 사람인척 위장을 할 위험이 있다.

 

Session의 순서

 1. 로그인을 진행하면 세션을 서버 메모리에 저장된다.

 2. 서버에서 브라우저의 쿠키에다가 Session Id (session 식별 정보)를 저장한다.

 3. 브라우저는 해당 사이트에 대한 모든 Reqeust에 Session Id를 전송한다.

 4. 클라이언트의 Session ID와 서버의 Session ID 를 비교하여 인증한다.

 

JWT 란?

 

JSON Web Token 의 약자이다. 인증에 필요한 정보들을 암호화시킨 토큰 기반을 의미합니다.

 

이 또한 쿠키처럼 클라이언트에 저장이 되기 때문에 서버의 부담을 덜 수 있고 토큰 자체에 권한, 정보를 가지고 있다.

 

JWT의 순서

 1. 클라이언트 사용자가 로그인을 통해 인증

 2. 서버에서 클라이언트에게 유일한 토큰 발급

 3. 발급받은 토큰을 저장해두고 서버에 요청을 할 때마다 전달받아 검증한다.

 4. 토큰에 담긴 정보를기반으로 권한 및 정보에 대해 응답한다.

JWT 의 구조

기본적으로 헤더, 내용, 서명으로 나뉘어져 있다.

Header

토큰 타입, 생성을 위한 알고리즘 저장

alg : 서명 암호화 알고리즘 (ex : HMAC SHA256, RSA)

typ : 토큰 유형

 

Payload

Payload 의 경우 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보의 내용을 담고 있다.

 

Signature

헤더에서 정의한 알고리즘 방식을 활용

Header 와 Payload 의 경우 인코딩 된 값이기에 3자가 복호화 및 조작할 수 있지만 Signature 는 서버 측의 비밀키가 유출되지 않는 이상 복호화 할 수 없다.