Computer Science/네트워크

Cookie vs Session vs JWT

eunnnn 2023. 6. 18. 23:03

쿠키와 세션을 사용하는 이유

http 프로토콜의 경우 Connectless, Stateless 한 특성을 가진다. 그렇기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 한다.

이러한 특성을 보완하기 위해 쿠키와 세션이 등장하게 된다.

 

  1. Connenctionless
    클라이언트와 서버가 요청과 응답을 한 번 주고받으면 연결을 끊어버리는 특징을 말한다.
    클라이언트가 request를 서버로 보내면 서버는 클라이언트가 보낸 request에 맞게 response를 보내고 연결을 끊는다. 
  2. Stateless
    위처럼 요청과 응답으로 인해 통신이 끝난다면 상태 정보를 유지하지 않는 특징이다.
    예를들어 메인페이지에서 로그인을 하고 다른 페이지로 넘어가면 다시 로그인을 해야된다.

 

Cookie

쿠키는 서버가 사용자의 웹 브라우저에 전송하는 key와 value로 이루어진 작은 데이터 조각으로, 클라이언트에 저장된다.

서버와 요청 응답으로 인해 쿠키가 저장되면 다음 요청은 쿠키에 담긴 정보를 이용해 참조한다. (동일한 서버에 재요청시 저장된 데이터를 함께 전송한다.)

 

  • 동작 방식
    1. 클라이언트가 로그인 요청
    2. 서버에서 쿠키 생성 후 클라이언트로 전달
    3. 클라이언트가 서버로 요청을 보낼 때 쿠키를 전송
    4. 쿠키를 이용해 유저 인증을 진행
  • 단점
    1. 보안에 취약하다. http 요청을 탈취당할 경우 쿠키 자체를 탈취당해 사용자 정보를 모두 빼앗길 수 있다.
    2. 작은 허용 용량을 가진다.
    3. 웹 브라우저마다 지원 형태가 다르다.
    4. 한번에 하나의 정보만 저장할 수 있다.
    5. 문자열 그대로 통신하여 위변조가 가능하다.세션
      세션은 쿠키를 기반으로 하지만 클라이언트에 저장하는 쿠키와는 다르게 서버에 저장하여 관리한다.
      서버에서는 클라이언트를 구별하기 위해 각각의 세션ID를 클라이언트마다 부여하게되며 클라이언트가 종료되기 전까지 유지한다.
      클라이언트에 저장하는 쿠키보다는 보안이 좋다.

 

Session

세션이란 일정시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.

세션은 중요한 정보를 클라이언트에 저장하는 쿠키와는 다르게 서버에 저장하여 관리하기 때문에 사용자 정보가 노출되지 않는다. 서버에서는 클라이언트를 구별하기 위해 각각의 세션 ID를 클라이언트마다 부여하게 되며 클라이언트가 종료되기 전까지 유지한다.

  • 세션 동작 방식
    1. 사용자가 아이디와 비밀번호로 로그인을 한다.
    2. 서버 측에서는 해당 정보를 검증한다.
    3. 정보가 정확하다면 서버 측에서 Set-Cookie를 통해 새로 발행한 SessionId를 보낸다.
    4. 클라이언트 요청 시 마다 서버에 저장된 세션Id와 클라이언트에 있는 sessionId가 일치 한지 확인한다.
  • 서버 기반 인증 문제점
    1. 서버 부하 : 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수에 따른 메모리나 디스크 또는 DB에 부하가 심하다.
    2. 확장성 : 사용자가 늘어나게 되면 더 많은 트래픽을 처리하기 위해 서버를 확장해야 하는데 서버를 확장할 때 세션의 저장되어 있는 서버로만 요청이 가도록 분산처리를 해줘야하기 때문에 서버를 확장하기 어렵다.
    3. CORS : CORS 방식을 사용할 때 쿠키 및 세션 관리가 어렵다.

 

JWT

JWT는 Json Web Token의 약자로, 인증에 필요한 정보들을 암호화시킨 토큰을 말한다.
세션 방식처럼 토큰 자체를 쿠키에 담아서 보내줄 수도 있고 HTTP 헤더에 담아서 보내줄 수도 있다.

  • 토큰 동작 방식
    1. 클라이언트가 로그인 요청
    2. 서버에서 유저의 고유한 ID와 다른 인증 정보들과 함께 Payload에 담는다.
    3. JWT의 유효기간 설정 및 옵션을 설정해준다.
    4. Secret Key를 이용해 토큰을 발급한다.
    5. 발급된 토큰은 클라이언트에 쿠키 혹은 로컬스토리지 등에 저장하여 요청에 보낼 때마다 같이 보낸다.
    6. 서버는 토큰을 Secret Key로 복호화하여 검증하는 과정을 거친다.
    7. 검증이 완료되면 대응하는 데이터를 보내준다.
  • 장점
    1. Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
    2. 인증 정보에 대한 별도의 저장소가 필요없다.
    3. JWT는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
  • 단점
    1. 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
    2. Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
    3. 토큰은 한번 발급 되면 유효기간이 만료될 때 계속 사용되어 탈취 당하게 되면 대처하기 힘들다.
  • 보안전략
    1. 짧은 만료기한 설정 : 토큰의 만료 시간을 짧게 설정하여 토큰이 탈취되더라도 빠르게 만료되기 때문에 피해를 최소화 할 수 있다. 그러나 사용자가 자주 로그인 해야 하는 불편함이 수반된다.
    2. Refresh token : 클라이언트가 로그인 요청을 보내면 서버는 Access Token 및 그보다 긴 만료 기간을 가진 Refresh Token을 발급하는 전략