[네트워크] 쿠키(Cookie), 세션(Session), 토큰(Token)

💡이걸 왜 쓸까?

• http 특징때문이다
• http는 웹에서 이루어지는 모든 데이터전송의 기본이 되는 프로토콜이다
• 이 http는 비연결성(connectionless), 비상태성(stateless)라는 특징을 가지고 있다
• 이런 특징으로 서버는 확장성이 높아진다는 장점을 가질 수 있다

 

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

 

문제점

 

한 사람이 웹사이트를 사용하기 위해 서버에 보내는 모든 요청은 연결성이 없어서 항상 다른 사용자로 인식하게 된다

웹사이트에 로그인하고 서버에 다른 요청을 보낸다면 서버는 현재 사용자가 로그인한 상태인지 아닌지 알 수 없다

 

 

쿠키

• 쿠키는 웹사이트에서 로그인, 검색기록 등 웹사이트에서 어떤 일을 했는지 쿠키에 저장한다
• 공개 가능한 정보를 사용자의 브라우저에 저장시킴 
• 웹사이트 재방문시 효율적으로 서비스를 제공한다
• 수정이 불가능한 중요한 정보들을 쿠키에 저장하는 것은 부적절하다
• 저장 위치 : 클라이언트의 웹 브라우저가 저장하는 메모리 또는 하드디스크
• 만료시간에 따라 해당 브라우저를 종료해도 남아있다

 

 

 

세션

 

• 사용자의 로그인 상태를 유지하기 위해 쿠키에 아이디와 비밀번호를 담아 두었다 
• 만약 이렇게 된다면 공용 컴퓨터에서 사용할 경우 개인정보가 유출될 것이다 http로 개인정보를 주고 받다보면 쿠키가 유출 되거나 조작이 될 수 있는 보안 문제들이 발생한다 

 

그리하여 이러한 점을 보안하기 위해 세션이 탄생하였다

 

• 세션은 중요한 정보를 서버에서 관리를 한다
• 그렇기 때문에 사용자가 직접 데이터를 수정할 수 없다
• 세션은 서버에 저장하기 때문에 사용자가 수백, 수천, 수만으로 늘어난다면 해당 유저의 정보를 찾고 데이터 매칭에 오랜 시간이 걸리면서 서버에 부하가 가해지게 된다
• 저장 위치 : 서버의 메모리에 저장
• 브라우저가 종료되면 만료시간에 상관없이 삭제된다

 

💡어떻게 식별할까?

1. 사용자가 접근을 하면 세션 ID라는 기간이 짧은 임시 키를 발급한다
2. 사용자는 이 임시 키를 가지고 있다가 해당 서버에 접근할때 세션 ID를 보낸다
3. 서버에서는 이 세션 ID를 가지고 사용자를 식별한다

 

 

토큰

 

만약 세션 ID를 사용자가 잃어버리게 된다면 어떻게 될까?

식별을 못한다

 

이런 점을 보안하기 위해 토큰이 탄생하였다

 

Authentication : 인증. 내가 누구인지 증명 ! 해주는 것.
Authorization : 인가. 음.. 너구나 ! ok 통과다

 

 

해당 서버에서 사용하는 비밀 키가 있다

비밀 키를 통해서 이 토큰이 유효한지, 토큰에 있는 데이터를 통해서 사용자를 식별한다

문자열로 되어있다

 

 

💡그럼 조작이 가능할까?

 

• 조작한 토큰을 서버에 요청을 하면 유효한 토큰이 아니기 때문에 막히게 되고 접근을 차단하게 된다

 

 

 

💡세션 보다 좋을까?

 

• 그건 아니다 토큰은 만약 여러 사용자가 한개의 계정으로 로그인을 한다고 했을때 만약 토큰이 유효한 토큰이면 모두 접속이 가능하다 
• 근데 세션을 사용하면 이미 접속한 적 있는 아이디로 다시 접속하는 경우는 막는다 던가 서버에서 컨트롤이 가능하다

 

 

구조 

 

• 토큰은 헤더(Header), 페이로드(payload, 서명(signature) 이렇게 세개로 구분하는 구조이다 

 

Header

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

 

Payload

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

 

Signature

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

 

 

 

장점

• header와 payload 를 가지고 signaure를 생성하므로 데이터 위변조를 막을 수 있다
• 인증 정보에 대한 별도의 저장소가 필요없다. (서버 부하 ↓)
• JWT는 토큰에 대한 기본 정보과 전달할 정보 및 토큰이 검증 되었다는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다
• 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다

 

단점

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

 

 

 

 

 

 

참고 : https://velog.io/@jung5318/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90