세션과 토큰을 사람이 말하듯이

은행은 아직 내가 누군지 모른다

TLS가 끝나면 브라우저와 은행 사이에 안전한 통로가 생긴다. 하지만 은행이 아는 건 "누군가와 안전한 통로가 생겼다"까지다. 그 누군가가 김상필인지, 내 비밀번호를 훔친 다른 사람인지는 모른다.

1편이 "이 사이트가 진짜일까?"였다면, 이번 편은 "이 사람이 진짜일까?"다.

확인은 두 단계로 나뉜다. 처음 한 번 "너 누구야"를 확인하는 단계(로그인), 그리고 그 뒤로 요청이 올 때마다 "아까 그 사람 맞다"를 이어 가는 단계(세션이나 토큰)다.

로그인, 비밀번호를 통로 안으로 보낸다

1. 아이디와 비밀번호를 1편에서 만든 통로 안으로 보낸다. 엿보는 사람에게는 잠긴 덩어리로만 보인다.
2. 은행은 비밀번호 원문을 저장해 두지 않는다. 1편 4장에서 본 것처럼, 솔트를 섞어 느린 해시로 계산한 값만 저장해 둔다.
3. 들어온 비밀번호를 같은 솔트, 같은 방식으로 계산해서 저장해 둔 값과 같으면 통과다.

Django는 비밀번호를 이런 모양으로 저장한다. 방식, 반복 횟수, 솔트, 해시값이 $로 나뉘어 한 줄에 들어간다.

pbkdf2_sha256$(반복 횟수, 수십만~백만)$(사람마다 다른 솔트)$(해시값)

헷갈리기 쉬운 점이 하나 있다. 비밀번호는 통로 안에서는 원문 그대로 간다. 해시는 은행이 저장하고 비교할 때 하는 일이다. 가는 길은 TLS가, 저장된 값은 해시가 지킨다.

웹은 요청마다 처음 보는 사람처럼 대한다

웹(HTTP)은 요청 하나하나를 따로 처리한다. 방금 로그인한 사람이 다음 페이지를 열어도, 서버 입장에서는 처음 보는 요청이다. 그렇다고 페이지를 열 때마다 비밀번호를 칠 수는 없다.

그래서 로그인에 성공하면 "나 아까 로그인한 그 사람이야"를 보여 줄 무언가를 받아 두고, 요청할 때마다 그걸 같이 보낸다. 그 무언가에 무엇을 담느냐에 따라 두 가지로 나뉜다.

세션은 찜질방 팔찌와 카운터 장부

찜질방에 들어갈 때 계산을 하면 번호가 적힌 팔찌를 준다. 팔찌에는 번호만 있고 이름은 없다. 매점에서 식혜를 사면 팔찌 번호만 보여 주고, 카운터 장부에 "37번 식혜 하나"가 적힌다. 나갈 때 정산하면 37번은 장부에서 지워진다.

팔찌 번호만 봐서는 누구 것인지 알 수 없다. 의미는 전부 카운터 장부에 있다. 그래서 세션을 "서버가 기억하는 방식"이라고 한다. 거꾸로 말하면, 장부에서 지우는 순간 그 팔찌는 바로 쓸모가 없어진다.

쿠키는 브라우저가 알아서 같이 보내는 메모

서버가 세션 ID를 건네는 방법이 쿠키다. 쿠키는 브라우저가 사이트별로 보관하는 작은 메모다. 그 사이트로 요청을 보낼 때마다 브라우저가 알아서 같이 보낸다. 그래서 내가 신경 쓰지 않아도 로그인 상태가 이어진다.

실제로 오가는 글자는 이렇다.

# 로그인 성공 응답 (은행 → 브라우저)
HTTP/1.1 302 Found
Location: /
Set-Cookie: sessionid=k3v9x2q8f1; HttpOnly; Secure; SameSite=Lax; Max-Age=1800

# 그 뒤의 모든 요청 (브라우저 → 은행)
GET /cameras/ HTTP/1.1
Host: wvp.idisman.co.kr
Cookie: sessionid=k3v9x2q8f1; csrftoken=…

쿠키 뒤에 적힌 옵션은 이 메모를 언제, 누구에게 보여 줄지 정하는 규칙이다.

"브라우저가 알아서 보낸다"는 편리함이 그대로 약점이 되기도 한다. 다음 장에서 본다.

통로가 안전한데 세션 ID는 어디서 털릴까?

TLS는 현금 수송차다. 운송 중에는 안전하다. 하지만 집에 도둑이 드는 것(브라우저 안), 수송차 없이 돈을 들고 걷는 순간(http), 누가 나인 척 심부름을 보내는 것(CSRF)은 수송차가 막을 수 없다. 쿠키 옵션은 집 보안이다.

HttpOnly는 세션 ID를 가져가는 것만 막는다. 스크립트가 내 화면 안에서 요청을 대신 보내는 것까지는 못 막는다. 그래서 스크립트가 아예 못 들어오게 막는 게 먼저다. Django 로그인 폼에 숨어 있는 csrftoken은 CSRF를 한 번 더 막는 장치다. 해커 사이트는 이 값을 알 수 없어서, 쿠키가 같이 가더라도 요청이 거부된다.

토큰은 놀이공원 자유이용권

놀이공원 매표소에서 표를 사면 손목띠를 채워 준다. 띠에는 "성인, 자유이용, 10월 26일까지"가 인쇄돼 있고, 매표소만 찍을 수 있는 도장이 있다. 놀이기구 직원은 매표소에 전화해서 장부를 확인하지 않는다. 띠에 적힌 내용과 도장만 보고 통과시킨다.

세션은 번호만 주고 내용은 장부에 두었다. 토큰은 반대로 내용을 다 적고, 고치지 못하게 서명한다. 1편의 서명, HMAC과 같은 원리다.

생긴 모양

JWT는 점(.)으로 나뉜 세 덩어리다. 아래는 이 페이지가 방금 실제로 계산해서 만든 토큰이다.

직원 계정을 지금 당장 막아야 한다면?

놀이공원 손님이 띠를 잃어버렸다. 매표소가 모든 놀이기구 직원에게 "이 띠는 무효"라고 일일이 알리기는 어렵다. 직원들은 원래 띠만 보고 통과시키니까. 토큰도 똑같다. 서버에 장부가 없어서 "이 사람 토큰만" 골라서 막을 방법이 없다.

짧은 토큰과 긴 토큰을 같이 쓴다

토큰이 털리거나 정지해야 할 때 피해를 줄이려면 수명을 짧게 하면 된다. 하지만 15분마다 비밀번호를 다시 치게 할 수는 없다. 그래서 토큰을 두 개 준다.

결국 리프레시 토큰 쪽은 장부를 다시 두는 셈이다. 토큰도 "장부가 전혀 없는" 방식은 아니고, 장부를 보는 횟수를 15분에 한 번으로 줄인 방식에 가깝다.

세션과 토큰, 무엇을 쓸까?

브라우저로 쓰는 사이트 하나이고, 권한을 바로 회수해야 하는 관제 시스템이라면 세션이 구조적으로 맞다. "요즘은 JWT"라는 이유만으로 바꾸면 오히려 손해일 수 있다.

WVP에 대 보면

로그인 주소 /login/?next=%2F는 Django의 기본 모양이다. "로그인이 끝나면 원래 가려던 /로 보내 달라"는 뜻이다.

한 장 요약

한 문장으로: 세션은 서버가 기억하고, 토큰은 들고 다니는 쪽이 증명한다.