Cookie, Session, Token

Backgrounds

인증(Authentication)

• 유저가 누구인지 확인하는 절차, 회원가입하고 로그인 하는 것

인가(Authorization)

• 유저에 대한 권한을 허락하는 것

Cookie와 Session이 필요한 이유

• HTTP 프로토콜은 비연결성(Connectionless), 무상태성(Stateless)을 지향한다. 때문에 클라이언트와 서버의 통신이 종료된 후 연결을 끊고 데이터 상태 정보를 유지하지 않는다.
• 이는 매 페이지를 이동할 때마다 로그인을 다시 하거나 상품을 선택했는데 구매 페이지에는 선택한 상품의 정보가 없는 것을 뜻한다.
• 따라서 웹 서버가 사용자의 상태 정보를 기억하기 위해 쿠키와 세션을 사용한다.

Cookie

• 쿠키는 세션에 비해 보안적인 측면에서 좋지 않다.
• 서버에 저장되지 않고 브라우저(사용자의 컴퓨터)에 저장되기에 서버 자원의 낭비를 방지할 수 있으며 빠르다.
• 브라우저가 종료되어도 쿠키에 설정한 만료 시간이 지나지 않으면 자동으로 삭제되지 않는다.
• 쿠키는 보안이 중요하지 않고 브라우저가 종료되어도 유지할 수 있는 정보에 사용된다.
• 활용 예: 주로 팝업창 "오늘 다시는 보지 않기" 로그인시 "id 기억하기" 체크, 비로그인시 장바구니 넣기

Session

• 클라이언트에서 관리하는 쿠키에 비해서 서버에 저장하는 세션은 보안이 좋다.
• 서버 자원을 사용하기 때문에 사용자가 많을 경우 자원을 많이 소모할 수 있다.
• 세션은 브라우저가 종료되면 자동으로 삭제된다. (만료기간 설정 가능)
• 세션은 주로 보안이 중요한 로그인 정보를 유지하는데 사용한다.

Session vs Token

세션 기반 인증

• 1. 유저가 로그인을 한다.
• 2. 로그인이 성공하면 서버는 메모리나 DB에 세션을 저장하고, 서버가 클라이언트(웹 브라우저)에 세션 ID를 전송하여 쿠키(Cookie)에 저장한다.
• 3. 브라우저는 로그인이 되었는지 확인하기 위해 매 요청시 Request에 Session ID를 쿠키에 담아 전송한다
• 4. 서버는 Session ID가 일치하는지 확인한 후 일치하면 요청에 응답한다.

세션 기반 인증 장점

• 서버 쪽에서 사용자의 로그인 상태에 확인이 쉽고 분명하다.
• 서버 쪽에서 세션 정보를 관리하기 때문에 클라이언트의 변조에 영향 받기 어렵고 데이터의 손상 우려가 없어 상대적으로 안전하다.
• 토큰 방식에 Signature 등 부가적인 정보가 없기에 Server-Clinet간 주로 받는 데이터가 적다.

세션 기반 인증 단점

• 대규모 서비스로의 스케일업을 위해서는 메모리에 저장되는 세션 정보로 인한 메모리 성능 부하가 있을 수 있다. Redis나 Memcached 등의 메모리 관리 시스템이 필요하다.
• 메모리에 저장된 세션 정보는 휘발성이기에 서버 재부팅시 사라질 수 있으며 많은 정보를 저장하는데 한계가 있다. 그렇다고 하드디스크나 DB에 저장하기에는 작업이 느리고 무겁다
• 쿠키는 단일 도메인, 서브 도메인에서만 작동하기 때문에 여러 도메인에서 사용할 경우 관리를 해줘야 한다.
  세션 정보를 메모리에 저장하기에 부담이 있다.

토큰 기반 인증 (JWT - JSON Web Token)

• 1. 토큰 기반 인증은 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내 유효성을 검사하는 방식이다.
• 2. 사용자가 로그인을 하면 서버측에서 계정 정보를 검증한다.
• 3. 검증이 완료되면, 서버측에서 클라이언트에게 signed token을 발급하고 클라이언트는 이를 저장한다. (signed token은 정상적으로 발급된 토큰임을 증명하는 signature가 있다는 것)
• 4. 클라이언트는 서버에 요청 시 저장된 Token을 Header에 포함시켜 보낸다.
• 5. 서버는 Token 정보를 검증하고 해당 유저에 권한을 인가한다.

토큰 기반 인증 장점

• 클라이언트가 토큰 정보를 갖고 있기 때문에 서버를 스케일업하는데 부담이 적다.
• 클라이언트 세션 관리에 대한 서버의 메모리 부담을 줄일 수 있다.
• 다양한 도메인에 대응하는데 부담이 적다.

토큰 기반 인증 단점

• 토큰 정보가 탈취될 수도 있어도 무효화할 수 없다. 보안에 취약하다.
• 토큰에 Signature 등의 부가적인 정보가 담겨 있기에 서버-클라이언트 간 주고 받는 데이터가 세션 기반의 인증보다 많다.
• 토큰 인증을 위해 Database에서 매번 조회해야 하므로 DB 성능 부하가 있을 수 있다.

로드 밸런싱을 수행하는 웹 서버의 경우 세션을 어떻게 관리할까?

1. 스티키 세션 (Sticky Session)

• 로드 밸런서가 쿠키가 없는 요청이라면 쿠키 값을 등록하고 웹서버를 지정한다.
• 쿠키가 있다면 해당 요청이 쿠키에 지정된 서버로 보낸다.

단점

• 로드밸런싱이 잘 동작하지 않을 수 있다.
• 고정된 세션을 사용하기에 특정 서버만 과부하가 올 수 있다.
• 특정 서버 Fail시 해당 서버에 붙어 있는 세션들이 소실될 수 있다.

2. 세션 클러스터링 (Session Clustering)

• 클러스터링은 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하도록 만드는 것이다.
• 즉, 각 서버의 세션에 모든 세션 저장소의 세션 객체를 복제한다.

단점

• 매번 세션 객체를 복제하는데 오버헤드가 발생한다.

3. 세션 스토리지 분리 (별도의 세션 저장소 사용 - Redis, MongoDB, DynamoDB..)

• 별도의 세션 저장소를 사용한다. 세션 저장소가 하나이기에 세션을 서버간 복제를 할 필요가 없다.
• 서버가 아무리 늘어난다 해도 세션 스토리지에 대한 정보만 각각의 서버에 입력해주면 세션을 공유할 수 있다. 또한, 트래픽이 몰리는 현상을 고려하지 않아도 된다.
• 하나의 서버가 장애가 발생해도 별도의 세션 저장소가 존재하기 때문에 서비스를 계속 제공할 수 있다. (가용성 확보)