[ Server ] Cookie vs Session (+JWT)

728x90

배경지식

* HTTP: HyperText Transfer Protocol의 약자로, 인터넷에서 정보를 송수신하는 프로토콜 (규약)입니다. HTML문서 송수신에 주로 사용됩니다.

* REST API: Repersentational State Trasfer API의 약자로, REST라는 규칙에 맞춰 개발 및 제공되는 API를 말합니다.

* API: Application Programming Interface의 약자로, 특정 서비스나 응용 프로그램에서 자신들의 서비스 내부의 기능들을 제어할 수 있도록 만들어놓은 인터페이스를 말합니다.

Server - Client의 연결유지

서버는 사용자가 요청한 정보를 처리하는 역할을 합니다.

즉 서버는 사용자가 누구인지, 어떤 행동을 했는지를 식별할 수 있어야 한다는 것인데, 그러기 위해서는 클라이언트에서 사용자에 대한 정보를 식별하여 보내주어야 합니다. 로그인이나 장바구니에 상품담기, 회원가입 등이 이와 관련된 작업에 해당됩니다.

하지만 웹 송수신 과정에서 사용되는 http는 아래와 같은 특징을 가지고 있습니다:

Connectionless (=비연결지향): 클라이언트가 서버에 정보수신이나 수정을 요청하면, 그에 맞는 작업을 완료한 후 연결을 종료합니다.Stateless (=상태정보 비유지): 클라이언트의 상태에 대한 정보를 프로토콜 상에서 가지지 않습니다. 즉 이전 통신에서 주고받은 데이터가 다음 통신에 그대로 유지되어 영향을 미치거나 처리될 수 없습니다.

이런 특징들을 굉장히 괴리적인데, 로그인을 한다고 해도 다시 홈화면으로 돌아가면 로그인이 풀려버리는 상황이 된다는 것과 같습니다.이런 문제를 해결하기 위해, 즉 상태정보를 유지하기 위해 사람들은 새로운 방법을 고안합니다

1. 연결정보를 "클라이언트"가 기억하게 하자 (=쿠키)2. 연결정보를 "서버"가 기억하게 하자 (=세션)

쿠키 (Cookie)

사용자를 식별하는 정보가 클라이언트에 저장되는 방식입니다.다시말해 사용자의 정보를 컴퓨터내부, 즉 웹브라우저 안에 저장하는 방식입니다.서버에서 별도 정보를 저장히지 않기 때문에 여러 서버를 거치면서 정보를 받아오거나 사용자가 많은 서비스에서는 이 방법을 사용합니다. 하지만 클라이언트에 저장하기 때문에 위변조의 위험성이 있습니다.

쿠키는 이름, 값, 만료일, 경로정보로 구성되며,1개당 4KB, 도메인당 20개, 클라이언트 도합 300개까지 저장할 수 있습니다.

통신 정책에 따라 윈칙적으로 타사이트의 쿠키는 받아올 수 없습니다 (=> CORS 정책)(만 설정하는 서버와 클라이언트에 특정 옵션을 주면 수정 및 설정이 가능합니다 (=> cross site cookie))

쿠키를 확인하는 방법은 개발자도구 > 어플리케이션 > 쿠키에서 보실 수 있습니다.만약 js를 할줄 아신다면, 개발자도구에서 아래 명령어로도 쿠키데이터를 확인하실 수 있습니다.다만, 명령어의 경우 HttpOnly로 설정되었다면 확인할 수 없습니다.

개발자도구에서 쿠키 확인:

명령어로 쿠키 확인:

세션 (Session)

사용자를 식별하는 정보가 서버에 저장되는 방식입니다.

다시말해 사용자의 정보를 서버의 특정 리스트안에 저장하는 방식입니다.

서버에서 정보를 저장하기 때문에, 비교적 변조의 위험성이 낮습니다. 하지만 쿠키에 비해 속도가 느리고, 서버에서 데이터를 저장하므로 사용자가 많은 서비스에서는 비효율적입니다.

세션은 쿠키와 달리 서버가 가능하다면 저장용량의 제한이 없습니다. 많은 정보를 유지해야 한다면 세션이 더 좋을 수도 있습니다.

세션은 설정되는 과정에 대한 약간의 이해가 필요합니다.

1. 사용자가 서버에 접속하면, 서버는 해당 사용자의 상태를 유지하기 위한 정보를 저장합니다. ㄴ 이 저장되는 정보는 임의의 키값과 대응되는데, 이 대응되는 값을 세션쿠키라고 합니다. 2. 세션쿠키가 설정될 때, 서버는 세션이 설정되지 않은 것으로 간주하고 session-id를 발급하여 클라이언트에 보냅니다. ㄴ 보낸 session-id는 'JSESSIONID'라는 이름으로 세션쿠키로 만들어 서버에 저장합니다.3. 다음 요청부터 클라이언트는 JSESSIONID를 이용하여 서버에 session-id를 전달하여 식별합니다.

결과적으로 세션도 쿠키를 기반으로 운용되지만, 서버에서 정보가 관리된다는 점이 특징입니다.

쿠키 vs 세션

\	쿠키 (Cookie)	세션 (Session)
저장	클라이언트	서버
형식	문자열	객체
상태 종료	설정된 시간이 지날 때	설정된 시간이 지날 때 or 브라우저가 종료될 때 (빠른쪽)
제한	20개 per 도메인 / 4KB per 쿠키	서버용량이 허용하는 한
속도	쿠키 > 세션
보안	쿠키 < 세션

서비스 사용자수, 유지할 정보, 유지기간 등을 고려하여 유동적으로 사용하는 것이 좋습니다.

최근에는 2가지를 혼용하여 사용하는 경우가 많습니다.

+) JWT

Json Web Token의 약자로, 인증에 필요한 json정보들을 암호화 시킨 토큰을 말합니다.

토큰은 3가지 요소로 이루어집니다:

Header: 정보에 대한 옵션들을 담고 있습니다. (암호화 알고리즘 등..)

Payload: 인증에 필요한 정보들을 담고 있습니다. (유저 고유 ID 등..)

Verify Signature: 'Header + Payload + Secret Key'된 값을 Secret Key로 암호화한 값이 들어갑니다.

형식은 위 3가지 형식을 .으로 구분한 문자열입니다. Header.Payload.VerifySignature형태로 이루어집니다.

Header와 Payload는 디코딩만하면 바로 풀리기 때문에 민감정보는 여기에 넣으면 안됩니다.

(따라서 JWT 또한 인증의 "유지"를 위한 수단으로 이용해야하며, 데이터를 저장했다가 가져오는 "저장소"로 이용하면 안됩니다.)

Header와 Payload의 변조를 통해 데이터가 변형되더라도, VerifySignature의 경우 앞의 2개 정보를 기반으로 암호화되어 있으므로 이 정보를 통해 JWT데이터의 변조여부를 판단할 수 있습니다.

JWT의 장점은 일단 세션보다 훨씬 간편하다는 점입니다. 별도의 저장소 관리가 필요하지 않으며 (쿠키의 장점), 문자열 1개만 클라이언트가 가지고 있는다면 로그인이 간편하게 유지됩니다(세션의 장점). 또한 서버가 예상치못한 오류로 인해 종료된다고 하더라도 서버가 다시 실행되었을 때 로그인이 풀리지 않습니다 (물론 세션의 경우에도 세션테이블을 저장하거나 백업서버와 공유한다면 풀리지 않습니다).

하지만 JWT의 경우 탈취당했을 때 서버측에서 유효성 검사를 막을 수 있는 방법이 없기 때문에 유효시간을 줄이고 Refresh 토큰을 사용하는 방법을 통해 피해를 최소화해야 합니다.