Cookie란?

• Cookie는 서버가 사용자 웹 브라우저에 전송하는 작은 데이터 조각입니다. 웹 브라우저는 서버로부터 받은 데이터 조각들을 저장해 놓았다가 서버에 요청할 때 Cookie에 저장된 데이터를 같이 전송합니다.

Cookie 사용 목적

• Session을 발급하고 Cookie에 Session ID를 담아 클라이언트에 전송함으로써 로그인 상태를 유지할 수 있습니다.

• 사용자만의 셋팅 값 또는 테마 등의 데이터를 저장할 수 있습니다.

• 쿠키에 담긴 사용자의 인터넷 사용기록을 이용하여 맞춤 광고를 제공할 수 있습니다.

Set-Cookie와 Cookie 헤더

• 서버는 HTTP 요청에 대한 응답을 할 때 Set-Cookie 헤더를 이용해서 Cookie에 저장할 데이터를 전송할 수 있습니다.

• 웹 브라우저는 서버에 요청할 때 Cookie 헤더를 이용해서 Cookie에 저장된 데이터를 요청에 담을 수 있습니다.

Cookie 속성

• Domain과 Path는 Cookie가 사용될 수 있는 Domain과 Path를 의미합니다.

• Secure는 HTTPS를 사용하는 경우에만 Cookie를 사용할 수 있습니다.

• HttpOnly는 XSS 공격을 방지하기 위해 JavaScript와 Document.Cookie API로 접근할 수 없게 하는 속성입니다.

Cookie의 종류

• Session Cookie는 메모리에만 저장되며 브라우저 종료 시 삭제합니다.

• Persistent Cookie는 디스크에 저장하여 브라우저가 종료되어도 유지되는 Cookie입니다. 주로 Session ID를 저장할 때 사용합니다.

• Secure Cookie는 HTTPS로 통신할 경우에만 사용하는 Cookie입니다.

• Third-Party Cookie는 방문한 도메인과 다른 도메인의 쿠키로서 주로 맞춤 광고에 사용되는 쿠키입니다.

Cookie의 단점

• 요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 당할 위험이 존재합니다.

• 4KB의 용량 제한이 있습니다.

• 웹 브라우저 마다 지원 형태가 다르며 브라우저간의 공유가 불가능합니다.

• 쿠키의 사이즈가 커질수록 네트워크의 부하가 상승합니다.

Session

• 세션이란 상호 연결 상태 정보를 공유함으로써 가상의 연결 상태를 구현하는 기법입니다.

• 웹 에서는 사용자가 로그인했을 때 Session을 발급하고 SessionID를 Set-Cookie 헤더를 이용해 클라이언트에게 공유하여 Session을 유지합니다.

• Session은 사용자의 요청이 있을 때마다 SessionID로 DB에서 Session을 조회해야 하는 추가적인 작업이 필요하다는 단점이 있습니다.

Session 방식의 단점

• 사용자의 Session ID를 탈취하여 서버에 접속할 수 있습니다.( 이를 위해서는 IP 제한 또는 접속 기기 제한을 이용해 추가적인 보안이 필요합니다. )

• 요청마다 SessionID로 DB에 저장된 Session을 조회해야 하기 때문에 DB 서버의 부하가 상승합니다.

토큰 인증 방식

• Token 기반 인증 시스템은 사용자가 로그인하였을 때 서버가 클라이언트에게 세션 정보가 담긴 토큰을 부여하고, 클라이언트의 매 요청마다 서버는 토큰이 유효한지만 검사하는 인증 기술입니다. Session에 대한 정보를 서버에서 관리하지 않기 때문에 Session 데이터 조회로 인한 서버의 부하를 없앨 수 있습니다.

Token 방식의 단점

• 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 트래픽이 증가합니다.

• Payload 자체는 암호화되지 않기 때문에 유저의 중요 정보는 담을 수 없습니다.

• 토큰을 탈취당하면 대처하기 어렵습니다. 그렇기 때문에 필수적으로 사용 기간 제한을 설정해야 합니다.

JWT( JSON Web Token )

• JWT(JSON Web Token)란 토큰 인증 방식에 사용되며, 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미합니다.

JWT 구조

• JWT는 Base64 URL-safe로 인코딩 되어있으며 '.' 을 구분자로 3 가지의 문자열인 Header, Payload, Signature로 구분됩니다.

• Header에는 서명 암호화 알고리즘과 토큰 유형이 담겨져있습니다.

• Payload에는 발행자, 만료 시간 등의 클라이언트 Session에 대한 정보가 담겨져 있습니다.

• Signature에는 Base64Url(Header) + . + Base64Url(Payload) + server's key에다가 Header에 있는 알고리즘 방식으로 암호화한 결과값이 저장되어 있습니다. server's key는 오직 서버만 알고있기 때문에 Signature를 통해서 해당 Token이 조작되었는지 여부를 확인할 수 있습니다.

JWT 장점

• 서버가 Session에 대한 별도의 저장 공간을 사용할 필요가 없습니다.

• 서버와 클라이언트간의 완전한 Stateless 구조를 갖기 때문에 확장성이 우수합니다.

• 모바일 어플리케이션과 호환성이 좋습니다.

JWT 단점

• Payload에 중요한 데이터를 담지 않도록 주의해야 합니다.

• 토큰의 크기 때문에 네트워크 트래픽이 증가할 수 있습니다.

• 토큰 자체가 탈취 당할 수 있기 때문에 토큰에 대한 유효기간을 지정해야 합니다.

Refresh Token

• JWT만을 사용할 경우 헤커가 사용자의 JWT를 탈취할 수 있습니다. 그렇기 때문에 Access Token과 Refresh Token 두개를 발급하여 실제 인증에 사용되는 Access Token의 유효기간을 짧게하고 만약, 만료되었다면 Refresh Token을 이용해서 재발급 받을 수 있도록 합니다. Refresh Token 또한 탈취 당할 수 있기 때문에 Access Token을 새로 발급 받을 때마다 새로운 Refresh Token을 발급하여 Refresh Token을 갱신시키는 방법을 주로 사용합니다. 이를 Refresh Token Rotation( RTR ) 이라 합니다.
  
  
  
• Refresh Token을 서버쪽에서 관리하여 사용자의 JWT를 갱신시켜주는 방법도 있습니다. 어떻게 본다면 Refresh Token을 서버에서 관리하는 것은 결국 서버에서 Session을 관리하는 단점과 동일하게 볼 수도 있습니다. 하지만, 서비스가 커짐에 따라서 필요한 사용자 정보가 커지지만 Refresh Token은 그대로이기 때문에 Session을 직접 관리하는 것보다는 훨씬 서버에 부하가 적습니다.

JWT vs Cookie & Session