매번 헷갈리던 이 세개의 개념을 정리하려고 포스팅을 작성했다.
* 쿠키 (Cookie)
HTTP 는 본래 정보를 유지하지 않는다. (stateless)
클라이언트와 서버 사이에 뭔가 통신이 필요하면 필요한 그 순간 마다 매번 요청을 하고 그에 대한 응답을 하는 구조로 되어 있다.
한번 클라이언트와 서버가 서로 연결이 이뤄지고 요청 응답이 완료되었으면 연결이 끊기는데 (connectionless)
HTTP 자체가 인터넷 상에서 불특정 다수와 연결되는 통신 환경을 만들기위해 설계되었기 때문이다.
서버가 다수의 클라이언트와 연결이 끊기지 않고 계속 연결되어 있으면, 연결 유지를 위한 Resource 가 너무 많이 필요하게 되어, 서버 관리 측면에 있어서는 단점으로 작용하기 때문이다.
그러나, 웹 기술이 발달하고, 사용자의 수요가 다채로워지면서 stateful 한 기능이 필요해졌다.
예를들면, 쇼핑몰 같은 사이트에서 초기의 HTTP 특징을 그대로 가지고 사이트가 만들어졌다 하면,
로그인 -> 상품 장바구니 담기 -> 로그인 -> 상품 구매 -> 로그인 -> 결제 .....
이런 중복되는 과정을 계속 거쳐야만 사용자가 소기의 목적을 달성 할 수 있게 된다.
이런 불필요한 작업을 제거하기 위해서 처음 등장한게 "쿠키" 이다.
이 쿠키란 웹 서버가 브라우저에게 지시해서 클라이언트의 메모리에 정보를 기록하는 파일을 말한다.
저 쇼핑몰 예제에서 쿠키를 썼다면, 로그인을 계속하지 않고,
이 클라이언트가 로그인을 한 상태임을 나타내는 정보가 쿠키에 담겨서 또 다시 로그인을 할 필요가 없게된다.
또한 쿠키는 항상 고정된 값을 갖고 있는 것은 아니며, 클라이언트가 웹 사이트를 방문할 때 마다 수시로 새로운 정보로 바뀐다.
쿠키는 아래와 같은 구성요소들을 갖는다
- 쿠키 구성요소
Name : 쿠키의 이름
Value : 쿠키의 값
Expires : 쿠키의 만료일을 설정한다
Domain : 쿠키가 사용되는 도메인을 지정
Path : 쿠키의 반환 경로를 설정 (도메인의 어느 부분을 이동하느냐에 따라 쿠키가 리턴됨)
Secure : 보안 연결 설정
HttpOnly : HTTP 외의 다른 통신 사용 가능 설정
- 쿠키의 종류
쿠키는 다양한 종류가 있는데 그것들은 아래와 같다
Session Cookie : Expire Date 를 설정하고, 클라이언트의 메모리에 저장되며, 브라우저 종료시 제거되는 쿠키
Persistent Cookie : 파일로 저장되는 쿠키로 브라우저의 종료 여부와 상관없이 유지됨
Secure Cookie : HTTPS 에서만 사용되는 쿠키, 쿠키 정보가 암호화 되어서 전송됨
Third-Party Cookie : 방문한 도메인과 다른 도메인의 쿠키를 의미함, 광고나 배너 등을 관리할때, 유입 경로를 추적하기 위한 용도로 쓰임
- 쿠키의 클라이언트 - 서버 전송과정
- 쿠키의 단점
민감한 개인정보 (결제 관련 정보, 아이디 비밀번호 등)를 쿠키에 담아서 연결할 경우, 쿠키가 외부에 노출되면, 보안상 문제가 생긴다
또한 쿠키에 대한 정보를 매번 HTTP Header 에 붙여서 보내야 하기 때문에 클라이언트 수가 많아지면, 트래픽이 커진다.
* 세션 (Session)
세션은 쿠키의 단점을 보완하기 위해서 등장했다.
쿠키의 경우 데이터가 브라우저에 저장되기 때문에, 외부 공격에 있어서 안전하지는 못한데,
이를 보완하고자 브라우저가 아닌 서버 쪽에 저장하자는게 세션의 개념이다.
- session 의 연결 구조
세션은 위 그림 처럼, 클라이언트가 접속한 서버에 저장되며, 클라이언트별로 Session id 를 부여받게된다.
Session id 의 경우 쿠키 형태로 브라우저에 저장되며, 브라우저 종료시에 사라지게 된다.
앞선 쿠키의 경우 stateful 한 모든 정보를 쿠키에 담아서 서버로 보내 인증을 해야 했지만,
session 의 경우 session id 만 전달해서 인증 받으면 되기 때문에, 트래픽 양도 줄어들고,
서버에 개인정보를 저장하기 때문에 상대적으로 쿠키보다는 보안상 안전한 편이다.
- 세션의 단점
클라이언트의 수가 많아지면 서버에 저장해야할 session 또한 많아지기 때문에 서버의 과부하를 일으킬 수도 있고,
서버가 여러대일경우, 한개의 클라이언트를 위한 세션 정보를 다른 서버들이 모두 가지고 있어야 서버를 분산해서 운영할때도, 클라이언트에 대한 인증 절차가 가능해진다.
* Token
토큰 방식은 보호해야될 데이터들을 token 으로 치환하여 원본 데이터 대신 token 을 기반으로 서버 클라이언트간 인증을 진행하는 방식이다.
토큰 기반의 인증과정은 아래와 같이 요약된다
클라이언트가 서버에게 로그인 요청을 보내고,
서버는 이에 맞춰 토큰을 생성해줘서 응답한다
그리고 이후 부터는 클라이언트가 요청할때 마다 토큰 정보를 붙여서 서버에게 요청하며, 이에 대한 응답을 주고 받는 구조이다.
이런 토큰 기반의 인증 방식은 앞선 쿠키의 단점 (브라우저에 저장시 정보 탈취 위험) 과 세션의 단점 (서버 분산 관리시 모든 서버가 클라이언트 각각의 정보를 모두 가져야한다는 점) 을 모두 커버해줄 수 있다.
인증 토큰 값 하나만 있으면 관련 모든 서버에서 인증되며, 브라우저에 직접 저장하는 방식도 아니어서 보안상의 큰 이점을 갖는다.
대표적으로 JWT (Json Web Token) 이 토큰 기반의 인증 방식이다.
- References
https://nesoy.github.io/articles/2017-03/Session-Cookie
https://victorydntmd.tistory.com/286
'BE' 카테고리의 다른 글
| DNS (Domain Name System) 란? (0) | 2020.08.21 |
|---|---|
| Load Balancing 이란 (0) | 2020.08.12 |