JWT / COOKIE / SESSION 차이점

 

 JWT / COOKIE / SESSION 차이점 

 

Cookie / Session 방식

Session/Cookie 방식 인증은 기본적으로 세션 저장소를 필요로 합니다.

세션 저장소는 로그인시 사용자 정보를 저장하고, 열쇠로 사용할 수 있는 세션 ID 를 만듭니다.

 

 

Cookie

쿠키는 일종의 서버와 클라이언트가 대화하기 위한 수단.

• 쿠키는 사용자의 정보를 사용자 컴퓨터 메모리에 저장한다

• 브라우저가 서버와 연결이 되었을 때 브라우저에서 자동적으로 쿠키를 생성하고,
  인증이 필요한 요청에 해당 cookie와 함께 서버에 request 를 보냅니다.
• 쿠키에 담긴 데이터는 브라우저에서 관리되며, 이름, 값, 만료 날짜, 경로 정보로 구성.

 

Session

서버와 클라이언트의 연결이 활성화된 상태.

• 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션 id를 부여,
  세션 스토리지에 세션 정보를 저장함.
• 클라이언트는 이 세션id를 쿠키를 통해 기억함.
• 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 cookie에 세션 id를 담아서 전송함.
• 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단
  (즉, 세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함)

 

 

Cookie / Session 로그인 과정 

 

사용자가 로그인을 합니다. 서버에서는 계정 정보를 읽어 사용자를 확인 후,

사용자의 고유 ID 값을 부여한 후 세션 저장소에 저장하고, 이와 연결되는 세션 ID 를 발행합니다.
클라이언트는 서버에서 해당 세션 ID 를 받아 쿠키에 저장 한 후,
인증이 필요한 요청마다 쿠키를 헤더에 끼워 보냅니다.

서버에서는 쿠키를 받아 세션 저장소에서 확인 한 후, 일치하는 정보를 가져옵니다.
인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.

 

Session/Cookie 인증의 장점과 단점

  장점

• 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거친다. 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 보면 된다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고있지 않다(중요 정보는 서버 세션에)
• 사용자 A는 1번, 사용자 B는 2번 이런식으로 고유의 ID값을 발급받게 된다. 그렇게 되면 서버에서는 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있어 서버의 자원에 접근하기 용이할 것이다.
  
  

  단점

• 완벽한 보안은 있을 수 없다! ㅠㅠ  해커가 인증된 사용자의 Cookie를 실어 서버에 요청을 보내면 서버는 인증된 사용자인지, 해커인지 구별할 방법이 없다.
  
  
• 세션 저장소라는 추가적인 저장공간을 사용하기 때문에 부하가 높아지게 된다

 

JWT 방식

JWT

JWT는 세션/쿠키와 함께 가장 대표적인 인증 수단이다.

JWT(JSON Web Token)의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다.

 

위의 세션/쿠키 방식과 유사하게 사용자는 Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송합니다.

토큰은 임의로 생성된 비밀번호 같이 동작합니다.

제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성돼야 합니다.

 

https://thdud4479.tistory.com/141

JWT - JSON Web Token

 

 

JWT 인증의 장점과 단점

  장점

• 간편하다.
  세션/쿠키는 별도의 저장소 관리가 필요하지만 JWT는 발급 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다.
     => 쿠키/세션 정보를 저장하지 않는 서버를 만드는 입장에서는 큰 강점이다. 
          이는 서버를 확장하거나 유지/보수 하는데 유리하다.
• 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능.
  예를들어 Facebook 로그인, Goggle 로그인 등은 모두 토큰을 기반으로 인증한다. 이에 선택적으로 이름이나 이메일 등을 받을 수있는 권한도 추가할 수 있다.

 

  단점

• 이미 발급된 JWT에 대해서는 돌이킬 수 없다.
  세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 되지만
  JWT는 한번 발급되면 유효기간이 완료될 때까지 계속 사용이 가능하다.
  악의적인 사용자는 유효기간이 지나기 전까지 정보를 털어갈수 있다;;;;
  
  
• Payload의 정보가 제한적이다.
  Payload는 따로 암호화 되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. (세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.
  
  
• JWT의 길이. 세션.쿠키 방식에 비해 JWT의 길이는 길다.
  따라서 인증이 필요한 요청이 많아질 수록 서버의 자원 낭비가 발생한다.