Cookie & Session & Token

들어가면서

최근 프로젝트를 진행하면서 Cookie와 Token에 대해서 공부를 한 적이 있다. 근데, 공부를 해도해도 헷갈리는 내용들이 많았기에 각각 무엇인지 어떤 특징들이 있는지에 대해서 정리를 해보도록 하겠다!

Cookie, Session, Token이 왜 필요했을까?

각각이 무엇인지 알기 전에 이것을 먼저 알아두고 가면 좋을 것 같다. 이 Cookie, Session, Token과 같은 방식들은 HTTP 통신의 단점을 해결하기 위해서 등장하였다.

HTTP 통신은 비연결성이라는 특징 때문에 로그인과 같이 자주 사용이 되는 정보들을 반복적으로 처리하게 된다. 그러나 이것은 반복적으로 작업하지 않도록 저장을 해두는 것이 더 효율적이다. 따라서 로그인과 같은 일을 할 때 누가 로그인 중인지와 같은 상태를 기억하기 위해 사용을 하게 되었다!

그렇다면 각각 어떤 특징이 있는지 알아보자!

Cookie란?

아마 인터넷을 좀만 하다보면 심심치 않게 등장하는 단어일 것이다. 특히 구글링을 해서 어떤 웹 사이트를 들어갔을 때 쿠키 허용하기 라는 글로 많이 봤을 것이다. 이 Cookie란 대체 무엇일까?

정의는?

HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일

간단하게 말해서 Cookie는 브라우저에 저장되는 작은 텍스트 조각으로 상태 정보를 유지하는 기술이다.

이 Cookie는 공개 가능한 정보를 사용자의 브라우저에 저장시킨다. 그렇다고 해서 이 Cookie가 속된 말로 털려도 된다는 뜻은 아니다. 다만 제 3자가 조회하는 것도 가능하기 때문에 보안상 민감한 정보를 저장하는데 적합하지는 않다.

특징은?

이 Cookie의 특징에는 무엇이 있을까?

• 개발자 도구에서 사용자가 Cookie를 확인하고 수정, 삭제할 수 있다.

• 이름, 값, 만료일(저장 기간 설정), 경로 정보로 구성되어 있다.

• 하나의 쿠키는 4KB까지 저장 가능하며 도메인 하나 당 최대 20개의 쿠키를 가질 수 있다.

• 세션보다 빠르지만 보안은 좋지 않다.
  : 위에서도 말했다시피 Cookie는 제 3자가 조회하는 것이 가능하기 때문이다..!
  

동작순서는?

Cookie의 동작 순서는 어떻게 될까?

1. 클라이언트가 페이지를 요청

2. 웹 서버는 Set-Cookie를 통해 쿠키를 생성

3. 생성한 Cookie에 정보를 담아 HTTP Header에 Cookie를 포함시켜 응답

4. 넘겨 받은 Cookie는 클라이언트가 보관하고 있다가 다시 서버에 요청할 때 요청과 함께 Cookie를 전송

5. 서버에서 Cookie를 읽고, 정보 변경이 필요할 경우 Cookie를 업데이트해 변경된 Cookie를 HTTP Header에 포함시켜 응답

6. 이후 동일 사이트 재방문시 클라이언트의 PC에 해당 Cookie가 있고 만료되지 않은 경우, 요청할 때 Cookie를 함께 전송

생명주기는?

Cookie는 자원이기 때문에 무제한으로 남겨놓지 않는다. 따라서 Cookie도 일정한 생명주기를 가지게 되는데 크게 2가지로 나뉜다.

• 세션 쿠키
  : Cookie를 생성할 때 만료 날짜 생략시 브라우저 종료시 까지만 유지

• 영속 쿠키
  : Cookie를 생성할 때 만료 날짜 입력시 입력한 날짜까지 유지
  

Session이란?

Cookie와 Session, Token과 같은 기술을 얘기할 때 로그인을 예시로 들었다. Cookie가 정보를 저장하는 것은 맞지만 만일 Cookie에 아이디와 비밀번호를 그대로 담아두고 있다면 개인 소유가 아닌 다른 컴퓨터에서 사용할 경우 사용자의 개인정보가 유출되는 문제가 발생한다. 이를 방지하기 위해서 Seesion이라는 기술이 등장하였다.

정의는?

클라이언트로부터 오는 일련의 요청을 하나의 상태로 보고 그 상태를 일정하게 유지하는 기술

이 Session은 클라이언트가 웹 서버에 접속해있는 상태가 하나의 단위로, 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.

Session은 비밀번호와 같은 인증 정보를 Cookie에 저장하는 것이 아니라 각 클라이언트에 고유한 Session ID를 부여하고 이를 저장한다. 이 Session ID로 클라이언트를 구분하여 각 클라이언트의 요구에 맞는 응답을 반환하게 된다.

다만 Session은 서버에 저장하기 때문에 사용자가 늘어날수록 해당 유저의 정보를 찾고 데이터 매칭에 오랜 시간이 걸리면서 서버에 부하가 가해지게 된다.

특징은?

Session의 특징에는 무엇이 있을까?

• Session ID만 Cookie로 저장하고 상태 데이터들은 서버에 저장한다.

• Session ID를 제외하고 서버에 저장되기 때문에 Cookie보다 보안성이 높다.

• 서버에 저장을 하기 때문에 서버의 부하가 늘어나고 상대적으로 속도가 느리다.

• 브라우저가 종료되면 소멸한다.

이 Session ID를 Cookie에 담아서 전송을 하는데, 이처럼 Cookie와 Session은 완전히 분리된 개념이 아니라는 것을 꼭 기억하자!

동작순서는?

Session의 동작순서는 어떻게 될까?

1. 클라이언트가 페이지를 요청(ex. 로그인)

2. 서버에서 계정 정보를 읽어 사용자를 확인하고, 사용자의 고유한 Session ID를 부여하여 Session 저장소에 저장한 후, 이와 연결된 Session ID를 발급

   : 흔히 영화관 티켓을 예시로 드는데 티켓을 보관용 부분만 찢어서 전해주듯이 Session ID를 사용자에게 전달하고 저장소에는 ID의 사본을 어떤 사용자의 것인지 적어서 보관을 해준다.

3. 사용자는 서버에서 해당 Session ID를 받아 Cookie에 저장 한 후, 인증이 필요한 요청마다 Cookie를 헤더에 실어 보냄

4. 서버는 Cookie를 받아 Session 저장소에서 대조 후 대응되는 정보를 가져옴

5. 인증이 완료 되고 서버는 사용자에 맞는 데이터를 보내줌

Token이란?

Session과 Cookie로 해결이 된거 아니야? 라고 생각할 수 있지만 아직 아니다. Session의 단점으로 서버에 부하가 걸릴 수 있다는 문제가 있었다. 이 서버의 부하를 해결하기 위해서 이 Token이라는 기술이 등장하게 되었다!

정의는?

사용자의 인증을 위해 사용되는 암호화된 문자열

💡 인증과 인가?
인증(Authentication)은 유저가 누구인지 확인을 하는 절차이다.
인가(Authorization)는 유저에 대한 권한을 허락하는 것이다.

서버 부하라는 단점을 해결하기 위한 방식으로 Token이 나왔다고 했다. 이 Token은 Session ID 대신 발급을 해주는 것이며, 여러 알고리즘 방식을 이용하여 암호화된 문자열로 발급을 하게 된다.

Token은 서버에서 발급을 해주는데 이 서버만 유효한 Token의 발행이 가능하다. 때문에 이 Token을 Cookie에 저장하고 요청을 할때마다 Token을 사용해서 인증할 경우 따로 확인을 할 필요없이 자신이 발급한 것인지 아닌지 여부만 판단해서 허가를 해줄 수 있고 이는 서버의 부하를 줄이는데 큰 도움이 된다.

동작순서는?

Token의 동작순서는 어떻게 될까?

1. 사용자가 서버에 요청을 보냄(ex. 로그인)

2. 서버가 사용자의 정보를 받아서 Token을 제작 후 발급

3. 사용자는 브라우저에서 Token을 받아 임시저장함

4. 사용자가 Token과 함께 서버에 요청을 보냄

5. 서버는 자신이 만든 Token이 맞는지 확인하고, 유효한 Token인 경우에만 올바른 응답을 보내줌

JWT란?

Token 하면 가장 먼저 생각이 나는 것이 바로 이 JWT이다. JWT가 무엇이고 어떠한 특징을 가지고 있는지 알아보자!

정의는?

정보를 비밀리에 전달하거나 인증할 때 주로 사용하는 토큰으로 JSON 객체를 이용함

JWT는 Json Web Token의 약자로 Token의 종류 중 하나이다. 이 JWT는 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용을 하는 Token이다.

구조는?

JWT는 Header, Payload, Signature 세 파트로 나눠져 있으며 각각이 의미하는 것은 다음과 같다.

• Header

  • JWT의 정보
  • 어떠한 알고리즘으로 암호화를 할 것인지, Signature시 사용하는 Key를 식별하는 값 등과 같은 정보를 담고 있음

• Payload

  • JWT의 내용
  • 클레임이라고 부르는 전달하려는 사용자의 id나 role 등의 데이터들이 들어있음
  • 노출과 수정이 가능하기 때문에 인증이 필요한 최소한의 정보만을 담는 것이 좋음

• Signature

  • 가장 중요한 부분
  • Header와 Payload를 합친 후 서버가 지정한 Secret Key로 암호화를 시켜 Token을 변조하기 어렵게 함
    ⇒ 만일 Payload의 정보가 조작이 됐을 경우 Signature 부분은 기존 Payload의 정보를 가지고 암호화를 시켰기 때문에 이 Payload가 다른 결과값이 나오게 된다. 이를 통해 Token이 조작이 되었는지 쉽게 확인할 수 있다.
    

장점은?

JWT의 장점으로는 무엇이 있을까?

• Header와 Payload를 가지고 Signature를 생성하기 때문에 데이터의 위변조를 방지할 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요없어 서버의 부하가 낮아진다.
• Token에 대한 기본 정보와 전달할 정보, Token이 검증되었다는 Signature 등 필요한 정보를 자체적으로 가지고 있다.
• Token은 한번 발급이 됐을 경우 유효기간이 만료될 때까지 사용이 가능하다.
  

단점은?

이렇게 많은 이점이 있지만 역시나 이 JWT에도 단점은 존재한다.

• Token의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화가 되지 않는다. ⇒ 민감한 정보나 보안상 중요한 정보들을 담아서는 안된다.
  
• 탈취당하면 대처하기 어렵다.
  

보안 전략은?

이러한 JWT의 단점을 보완하기 위해서 사용하는 보안 전략들이 존재한다.

1. 짧은 만료 기한 설정
   : Token의 만료시간이 짧으면 탈취가 되더라도 금방 만료가 되기 때문에 피해를 최소화할 수 있다. 다만 그만큼 사용자가 로그인을 자주 해야하는 문제가 있다.
   

2. Sliding Session
   : Session을 유지하는 사용자에게 자동으로 Token의 만료 기한을 늘려주는 방식이다. 이 방식을 사용하게 된다면 로그인을 자주 해야한다는 단점이 보완되지만 그와 반대로 로그인을 전혀하지 않아도 되는 문제가 발생하게 된다.

3. Refresh Token
   : 위에서 얘기하는 Token을 Access Token이라고 한다. 이때 이 Access Token보다 만료시간이 긴 Refresh Token을 따로 하나 더 만들어서 사용을 하게 된다면 Access Token이 만료가 되었을 때 Refresh Token을 사용하여 Access Token을 재발급을 받을 수 있다. 다만 이 구현 과정이 복잡하며 서버에 별도의 저장소를 만들어야 하기 때문에 JWT의 Stateless라는 장점이 없어진다.

정리하자면

Cookie와 Session, Token은 HTTP의 비연결성과 무상태성으로 인한 불편함을 해결하기 위해 나왔다!

Cookie는 간단한 정보를 기억할 수 있는 수단이다!

Session은 계속 서버와 연결을 유지할 수 있는 인증서와 같은 역할을 한다!

Token은 사용자 인증을 위해 사용되는 기술이며 그 자체로 인증서의 역할을 한다!