Session/Cookie/Token 특징 및 차이

Session?(세션)

 

클라이언트(사용자 혹은 브라우저)와 웹 서버 간에 통신 연결에서 두 개체의 활성화된 접속을 뜻하는 것으로 

클라이언트가 웹 서버에 요청하여 처음 접속 하게 되면 클라이언트에게 특수하고 유일한 ID 값을 부여하게 되고

부여받은 ID 값을 세션이라고 한다.

서버에서 생성된 세션은 클라이언트에서 쿠기를 통해 저장되며 클라이언트가 웹 서버에 요청을 보낼 때 세션을 같이 보내면 현재 요청을 보내는 사용자가 누구인지 웹 서버는 세션을 통해 알 수 있다.

 

세션의 장점

• 서버에 데이터가 저장됨으로 클라이언트에 사용자 정보가 노출될 위험이 적다.
• 서버가 허용하는 한 용량의 제한이 없다.

세션의 단점

• 브라우저 종료 시 세션은 삭제된다.
• 쿠기에 비해 속도가 느리다.

세션의 동작 순서

1. 클라이언트가 웹 서버에 요청을 한다.(사용자가 브라우저를 통해 웹사이트에 접속)
2. 웹 서버가 클라이언트가 보내온 Request-Header 정보 중 Cookie를 확인하여 session-id 값이 포함되어 있는지 확인
3. session-id 값이 없는 경우 서버가 ID를 생성하여 클라이언트에게 보내고 클라이언트는 해당 Id 값을 쿠키에 저장
4. 클라이언트가 다시 동일한 웹 서버에 요청할 때 쿠키에 저장한 session-id 값을 같이 보낸다.

 

Cookie?(쿠키)

사용자가 웹사이트에 접속할 경우 웹사이트가 상요하고 있는 웹서버에서 사용자의 컴퓨터에 저장하는 것으로 필요시 저장된 정보를 참조하거나 재 사용할 수 있다.

 

쿠키의 장점

• 만료시점이 지나지 않으면 브라우저를 종료해도 삭제되지 않는다.
• 세션에 비해 빠르다.

쿠키의 단점

• 용량의 제한이 존재한다.
• 보안에서는 세션보다 약하다.

쿠키의 동작 순서

1. 클라이언트가 웹 서버에 요청을 한다.(사용자가 브라우저를 통해 웹사이트에 접속)
2. 웹 서버는 쿠키를 생성
3. 생성한 쿠키 정보를 클라이언트가 보낸다.
4. 웹 서버가 보내는 쿠키 정보를 클라이언트의 PC에 저장
5. 웹 서버 요청 시 쿠키도 함께 전송

 

Token?(JWT)

유저의 정보를 Base64로 인코딩 된 String 값에 저장하는 도구로 Header, Payload, Signature로 구성되어 있는 것으로

서버에서 생성되어 클라이언트에 저장된다.

클라이언트가 요청을 보낼 때 TokenId 값을 같이 보내면 웹 서버는 현재 요청을 보내는 사용자가 누구인지 알 수 있다.

Signature 값을 이용하여 검증을 진행한다.

 

토큰의 장점

• 서버에서는 별도의 세션 및 쿠키 정보를 저장할 저장소 관리가 필요 없다.

토큰의 단점

• 토큰 정보 노출 시 유효기간이 경과되기 전까지는 변경이 불가하다.
• 인증에 필요한 요청이 많아질수록 서버의 자원낭비가 발생한다.
• payload는 암호화가 되지 않아 유저의 중요한 정보를 담기에 부담스럽다.

토큰의 동작 순서

1. 클라이언트가 웹 서버에 요청을 한다.(사용자가 브라우저를 통해 웹사이트에 접속)
2. 웹 서버에서 계정 정보를 읽어 사용자 확인 후 JWT 토큰의 유효기간을 설정 후
   암호화할 Secret Key를 이용하여 Access Token을 발급
3. 클라이언트는 Access Token을 받아 인증이 필요한 요청마다 Acceess Token 정보를 Header에 같이 보냄
4. 웹서버는 해당 토큰의 Signature를 Secret Key를 이용하여 복호환 후 변경여부 및 유효기간을 확인
5. 검증이 완료 되면 Payload에 Base 64로 인코딩 된 정보를 디코딩하여 데이터를 가져옴