[WEB] 쿠키(Cookie), 세션(Session), 토큰(Token)에 대해 정리해보자

1. 특징 및 장단점

들어가기 전 쿠키, 세션 같은 개념이 왜 나왔는지부터 알아보자.

간단히 말하면 HTTP의 Stateless(무상태성)과 Connectionless(무연결성) 특징 때문에 쿠키와 세션을 사용하는 것이다.

• Connectionless(무연결성): 서버와 클라이언트 간의 통신은 연결 수립 - 요청 - 응답 - 연결 제거 순으로 진행된다. 즉 응답이 완료되면 클라이언트와 서버의 연결은 끊어진다.

• Stateless(무상태성): 클라이언트가 요청A를 보내고 곧바로 요청B를 보낸다고 해도 서버는 클라이언트가 이전에 요청을 보냈던 클라이언트인지 구분하지 못한다. 간단히 말하면 http 요청은 독립적이며 서버는 클라이언트의 상태를 기억하지 못한다.

 

이러한 특징으로부터 갖게 되는 장점은 불특정 다수를 대상으로 하는 서비스에 적합하다는 것이다. 서버와 클라이언트의 연결이 지속되지 않기 때문에 클라이언트-서버 간 최대 연결 수보다 훨씬 더 많은 요청 및 응답을 처리할 수 있기 때문이다. 반면, 단점으로는 응답이 완료되면 연결을 끊어버리는 관계로 클라이언트의 이전 상황을 알 수 없다는 문제가 있다. 이럴 때 cookie(쿠키)를 사용하면 http의 단점을 보완하여 사용자를 식별하고 상태를 유지할 수 있다.

 

쿠키(Cookie)

출처: https://tomining.tistory.com/172

• 사용자 식별할 때 필요한 데이터 조각

• 요청이 처음 들어왔을 때 서버는 응답과 함께 Set-Cookie header를 브라우저(클라이언트)에게 전송한다. 서버로부터 쿠키를 전달받은 브라우저는 이를 저장해 놓았다가 동일한 서버에 재요청을 할 경우 저장된 쿠키를 header의 Cookie로 전달한다

• 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용한다

• Expires 혹은 Max-Age를 설정하면 명시된 기간까지 쿠키가 유지된다

 

쿠키를 사용하는 목적은 아래와 같다

• 세션 관리(Session management): 서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리

• 개인화(Personalization): 사용자 선호, 테마 등의 세팅

• 트래킹(Tracking): 사용자 행동을 기록하고 분석하는 용도

 

장점	단점
-  쿠키는 웹 브라우저에 저장되기 때문에 서버의 저장공간을    절약할 수 있다 -  처리 속도가 세션보다 빠르다	- 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터   위변조의 가능성이 높아 보안에 취약하다

 

세션(Session)

출처: https://tansfil.tistory.com/58

쿠키의 단점을 보완하는 방법으로 세션(session)을 사용할 수 있다.

• 서버에 사용자 식별 값인 session id와 이에 대응하는 사용자 정보를 저장한다. 클라이언트가 맨 처음 요청을 하면 서버는 클라이언트에게 session id를 전달한다. 이후 클라이언트가 session id를 헤더 쿠키에 넣어 요청을 하면 서버에서는 해당 session id와 대응하는 사용자 정보 통해 사용자를 식별한다

• session id는 브라우저 단위로 저장되고 브라우저 종료 시 소멸된다

• 로그인한 사용자에 대해서만 세션을 생성하는 것이 아니기 때문에 로그아웃하면 새로운 사용자로 인식해서 새로운 세션이 생성된다

• 필요한 정보들을 세션에 담아두면 요청이 들어올 때마다 DB에 접근할 필요가 없어서 효율적이다

 

장점	단점
- 서버에 저장되기 때문에 웹 브라우저에 저장되는 쿠키에 비해   보안이 좋다 - 클라이언트와의 통신을 할 때 session id만 보내기 때문에   세션의 네트워크 부하가 낮다	- 서버에 저장하기 때문에 저장해야 되는 데이터가 늘어나면   서버 부하가 생긴다 - 서버에서 처리해야 되기 때문에 쿠키보다 속도가 느리다 - 세션 정보 역시 중간에 노출될 수 있기 때문에 보안이   완벽한 것은 아니다

 

토큰(Token)

쿠키와 세션의 단점을 보완하기 위해 토큰이라는 개념이 등장했고 이를 통해 HTTP 통신의 Stateless 특성을 유지하면서도 사용자 식별이 가능해졌다. 

• 사용자가 로그인을 하면 서버는 해당 사용자에 대한 계정 정보를 확인한다. 올바른 사용자인 게 확인되면 서버는 singed token을 발급한다. 클라이언트는 발급받은 token을 저장한다. 이후 서버에 요청을 보낼 때마다 저장해둔 token을 HTTP header에 담아 함께 보낸다. 서버는 token을 검증하고 요청에 응답한다
• Stateless 특징 덕분에 서버 확장이 유연하다
• 정보가 담긴 데이터를 암호화하여 HTTP header에 담아 전달하기 때문에 쿠키를 사용할 때와 같은 보안 취약점은 사라지겠으나, 만약 중간에 토큰이 탈취된다면 이 토큰을 이용해 다른 사람이 권한을 수행할 수 있으므로 완전히 안전한 방법은 아니다
• 토큰 기반 인증 방식 중 많이 사용되는 JWT(JSON Web Token)의 경우, HMAC를 이용해 무결성을 보장하기 때문에 변조된 토큰일 경우 바로 알 수 있다. jwt 홈페이지에서 확인해보면 동일한 payload일지라도 secret key를 통해 token값이 달라지는 것을 확인할 수 있다
• 로그인 정보가 사용되는 분야가 확장된다. OAuth를 통해 github, google 등의 다른 서비스 계정으로 로그인할 수 있으며, 토큰에 선택적 권한만 부여함으로써 서비스를 특정 수준까지 이용하게끔 하는 것도 가능하다

출처: https://www.groundai.com/project/json-web-token-jwt-based-client-authentication-in-message-queuing-telemetry-transport-mqtt/1

 

 

장점	단점
- Stateless이면서 사용자 식별이 가능 - 무결성 보장  - 로그인 기능 확장성 좋음	- 토큰이 한 번 발급되면 만료되기 전까지 사용할 수 있다. 즉 토큰이    탈취되면 다른 사람에 의해 토큰이 이용될 수 있다

 

 

 

마치며

정리하며 느낀 점은 자신이 만들고자 하는 서비스와 환경을 파악하고 그에 맞는 방식을 선택하면 된다는 것이었다. 추후 서비스가 커질  가능성이 있는지, 서버 리소스가 부족하지는 않은지, 또는 다른 서비스들과 연동할 것인지 등을 잘 고려하며 사용해야 나중에 삽질을 줄일 수 있을 것 같다. 다음에는 토큰 사용 시 발생할 수 있는 보안 문제를 어떻게 하면 대비할 수 있을지에 대해 공부하고 포스팅해야겠다.

 

---

참고 문서

• https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

• https://server-engineer.tistory.com/152

• https://cjh5414.github.io/cookie-and-session/

• https://medium.com/@youngsoojung/node-js%EC%99%80-vue-js-%EA%B0%84%EC%9D%98-%EC%9D%B8%EC%A6%9D-%EA%B6%8C%ED%95%9C-1%EB%B6%80-443ebe122f74

• https://victorydntmd.tistory.com/115

• https://mangkyu.tistory.com/55