세션과 쿠키 / 토큰(JWT)

bshunter·2023년 7월 20일

세션 방식과 토큰 방식에 대한 이해

요즘 웹 개발에서 인증 및 인가는 중요한 부분입니다. 인터넷 사용자가 증가하며 다양한 웹 애플리케이션이 등장하면서 몇 가지 인증 방식이 생겼습니다. 이 글에서는 주로 사용되는 두 가지 인증 방식인 세션 방식과 토큰 방식에 대해 설명하고, 어떤 환경에 어떤 인증 방식이 바람직한지 살펴봅시다.

세션의 동작 원리

클라이언트가 처음 서버에 요청을 보낼 때, 서버는 세션을 생성하고 세션 ID를 생성합니다.
서버는 생성된 세션 ID를 HTTP 응답 헤더에 포함된 Set-Cookie에 설정하여 클라이언트에게 전달합니다.
클라이언트의 웹 브라우저는 이 세션 ID를 쿠키로 저장합니다.
클라이언트가 추가 요청을 보낼 때마다 브라우저는 해당 쿠키를 포함하여 HTTP 요청 헤더에 전달합니다.
이렇게 함으로써 서버는 각 요청이 동일한 클라이언트로부터 온 것을 인식하고, 저장된 세션 데이터에 접근할 수 있습니다.
서버는 요청에 포함된 쿠키에서 세션 ID를 추출하고 세션 저장소에서 해당 세션 ID와 연결된 데이터(상태)를 사용하여 작업을 수행합니다.

그래서 이게 무슨 말인데?

세션과 쿠키를 이용해 로그인 하는 과정을 도서관을 예를 들어 설명하겠습니다.

도서관 가입 및 쿠키 발행
사용자가 도서관에 처음 도착하여 대출증을 발급 받습니다.(첫 요청)
도서관은 사용자의 인적사항 (세션ID) 이 적힌 가입신청서를 받아 도서관 회원목록 (DB) 에 회원 번호와 함께 인적사항을 기록합니다.
그 후, 사서에게 내 이름(세션ID)가 적힌 대출증(쿠키) 을 받게 됩니다.

이 과정은 클라이언트가 처음 서버에 세션ID를 적어 요청을 보내고, 서버가 세션ID를 기록한 쿠키를 발급한 후 클라이언트에게 전달하는 것에 해당합니다.

도서관 회원증 확인
사용자가 도서관에서 도서를 대출하려 할 때마다 사서는 대출증(쿠키)을 확인하여 사용자를 인증합니다. 사용자는 도서관을 이용할 때마다 대출증(쿠키)을 제시해야 합니다.

이 과정은 클라이언트가 요청을 보낼 때마다 서버가 쿠키를 사용하여 사용자의 로그인 상태를 확인하는 것에 해당합니다.

도서 대출 및 반납 기록 저장
사용자가 도서를 대출하면 도서관은 사용자의 대출 기록을 저장합니다.
사용자가 도서를 반납하면 도서관은 해당 기록을 업데이트합니다.
도서관에서는 사용자별로 도서 대출 및 반납 기록을 유지합니다.

이 과정은 서버가 로그인된 사용자에 대해 개별 세션 데이터를 저장하고 조회하는 것에 해당합니다.

도서관에 처음 갔을때만 대출증을 발급 받는다는 사실을 기억하세요

대출증 발급 목록을 사서가 직접 관리한다는 사실을 기억하세요

토큰(JWT)의 동작 원리

토큰 요청:
클라이언트가 서버에 로그인 요청을 보냅니다.
이 요청에는 사용자 ID와 비밀번호와 같은 사용자 자격증명이 포함됩니다.
토큰 발급:
서버는 사용자 자격증명을 검증하여 외부 인증 공급자(Identity Provider, IdP)를 이용해 토큰을 생성합니다.
토큰에는 사용자 정보, 발급 시간, 만료 시간 등 토큰에 대한 메타데이터가 포함됩니다.
토큰 전달:
서버는 생성된 토큰을 클라이언트에게 응답으로 전달합니다. 클라이언트는 이 토큰을 저장하고 사용합니다.
토큰 사용:
클라이언트는 이후 요청에 토큰을 전달합니다.
일반적으로 HTTP 요청 헤더의 Authorization 필드에 토큰을 넣어 전달합니다.
토큰 검증:
서버는 요청에 포함된 토큰을 검증합니다. 토큰의 유효성, 만료 여부 등을 확인한 후,
해당 요청에 대한 인가를 결정합니다.

이건 이해가 쉬운데?

토큰 방식이 세션 방식보다 이해하기 쉽게 느껴지는 것은 완전히 정상입니다.
이 두 방식의 주요 차이점 중 하나는 토큰 방식이 무상태(stateless) 특성을 가지고 있다는 점입니다.

무상태 특성으로 인해 서버는 사용자 상태를 추적하고 유지할 필요가 없어지며,
사용자가 토큰을 가지고 있으면 언제든지 요청을 보낼 수 있습니다.
이 점은 토큰 인증 방식의 이해를 더욱 간단하게 만듭니다.

이와 달리, 세션 방식은 클라이언트-서버 간 상태 유지와 별도의 세션 저장소 역할을 수행해야 하는 등
일부 추가적인 복잡성이 있습니다.

아래는 토큰 방식의 예시입니다.

항공권 예약 / 토큰 발급
사용자가 웹사이트나 애플리케이션을 통해 항공권 티켓을 예약합니다.
웹사이트나 애플리케이션 은 예약 정보를 확인하고, 사용자를 인증하기 위한 전자 티켓을 발급합니다.
전자 티켓에는 사용자의 정보와 항공편 정보가 포함되어 있습니다. 사용자는 이메일로 전자 티켓을 전달받습니다.

이 과정은 클라이언트가 사용자 정보를 입력하여 서버에 인증 요청을 보내고,
외부 인증 공급자(웹사이트나 애플리케이션)가 사용자 정보를 확인한 후 토큰(전자 티켓)을 발행하는 것에 해당합니다.

항공권 저장 / 토큰 저장
사용자는 전달받은 전자 티켓을 스마트폰 애플리케이션이나 프린트하여 보관합니다.
공항에서 승객 인증 및 탑승 과정에서 전자 티켓을 제시해야 합니다.

이 과정은 클라이언트가 외부 인증 공급자로부터 전달받은 토큰을 로컬 스토리지, 세션 스토리지 또는 쿠키 등의 클라이언트 측 저장소에 저장하는 것에 해당합니다.

항공권 사용 / 토큰 사용 및 인증
사용자는 공항 직원이 아닌 자동화 티켓 승인 기계에 전자 티켓을 제시하여 승객 인증 절차를 밟습니다.
자동화 티켓 승인 기계는 전자 티켓을 검증한 후 승객의 예약 정보와 항공편 정보를 확인하고 입국 및 탑승 여부를 결정합니다.

이 과정은 클라이언트가 요청 시 토큰(전자 티켓)을 서버에 전달하고, 서버는 토큰을 외부 인증 공급자에게 보내어 검증하고 인증 및 인가를 처리하는 것에 해당합니다.

사용자에게 전자 티켓을 발급함으로써 공항 직원의 부담이 줄고 사용자 또한 편리한 인증이 가능합니다.

항공사가 아닌 다른 판매자가 티켓을 발급해준다는 사실을 기억하세요

공항직원이 아닌 자동화 티켓 승인 기계가 인증을 해준다는 사실을 기억하세요

세션 방식과 토큰 방식의 차이점

세션 방식은 클라이언트와 서버 간의 상태를 유지하면서 인증을 처리하는 방식입니다. 사용자가 로그인하면 서버에서 세션을 생성하고 클라이언트에 세션 ID를 쿠키로 저장하여 사용자를 인증합니다.

토큰 방식은 사용자 인증 정보를 토큰에 담아 전달하는 무상태 인증 방식입니다. 서버는 사용자 상태를 추적하거나 유지할 필요가 없으며 클라이언트는 토큰을 이용하여 인증 정보를 저장 및 관리합니다.

그래서 뭐가 다른건지 잘 모르겠어

세션 방식과 토큰 방식의 가장 중요한 차이점은
"관리자가 직접 대출증/티켓 을 발급해 주는지 , 관리자가 승인목록 을 가지고 있는지"
의 차이 입니다.

이러한 차이로 인하여 두 인증 방식은 확장성, 성능, 보안 등의 측면에서 다른 특징을 갖습니다.

확장성과 성능
세션 방식에서는 도서관의 사서가 직접 대출증 발급 회원 목록을 관리하기 때문에,
사서 (서버) 의 부담이 커집니다. 이로 인해 확장성과 성능이 제한될 수 있습니다.
토큰 방식에서는 자동화 티켓 승인 기계가 승인 절차를 처리하고 있으므로,
공항 직원(서버) 는 사용자 인증에 대한 부담이 없어지고, 확장성 및 성능이 개선됩니다.
보안
세션 방식에서는 도서관의 사서가 직접 대출증 발급 회원 목록을 관리하기 때문에,
외부에서의 대출증 발급 회원 목록에 접근이 제한되고 그로 인한 보안상의 이점이 있습니다.
토큰 방식에서는 사용자의 인증 정보를 자동화 티켓 승인 기계 관리하기 때문에,
타인이 전자 티켓을 훔친다면 보안상의 문제가 생길 수 있습니다.
그렇기에 티켓을 안전하게 저장하고 관리하는 것이 중요합니다.
분산 시스템과 로드 밸런싱
서버 중심의 세션 방식에서는 서버 간에 세션 정보를 동기화하는 데 어려움이 있을 수 있습니다.
이에 따라 로드 밸런싱이나 분산 시스템 환경에서는 관리가 복잡해질 수 있습니다.
토큰 방식에서는 사용자의 인증 정보가 토큰에 포함되어 있으므로 분산 시스템 및 로드 밸런싱에 적합합니다.