[TIL-171] Session

세션 & 토큰 & 쿠키

쿠키

쿠키는 서버가 브라우저에 데이터를 넣는 수단. 도메인에 따라 제한됨. 서버가 정한 유효기간 있음. 인증(세션)뿐 아니라 웹사이트 언어설정 등의 정보를 담을 수 있음.

1. 브라우저의 요청에 서버가 응답할 때 쿠키를 보냄.
2. 쿠키가 브라우저에 저장됨.
3. 이제 해당 웹사이트에 방문해서 요청할 때마다 브라우저는 자동으로 쿠키를 함께 보냄.

 

HTTP

http 프로토콜은 무상태(stateless)임. 서버에 보내는 모든 요청이 이전 요청과 독립적으로 이뤄짐. 따라서 요청이 끝나고 다시 요청 보내면 서버는 누군지(같은 사용자임을) 알 수 없음. 그래서 사용자 인증을 위해 세션이나 토큰을 사용함.

 

세션

1. 어떤 사용자가 id와 비밀번호를 통해 로그인에 성공하면, 서버는 세션 DB에 해당 유저를 생성함.
2. 이 세션의 ID를 보내 쿠키를 통해 브라우저에 저장함.
3. 따라서 같은 웹사이트 안에서는 브라우저가 항상 이 세션 ID를 가진 쿠키를 서버에 보냄.
4. 서버는 이 쿠키 안의 세션ID를 확인할 수 있음. 세션 DB에서 이 세션 ID를 가진 유저를 찾음.

매번 이 과정을 통해 유저를 확인함. 중요한 유저 정보는 모두 서버에 있음. 유저는 세션 ID만 갖고 있음. 쿠키는 세션 ID를 전달하기 위한 매개체. 쿠키에 공간 제약이 있어서 세션 ID는 토큰보다 짧음.

하지만 브라우저와 달리 네이티브 앱(ios, 안드로이드)에는 쿠키가 없어서 토큰을 사용해야 함.

요청이 들어올 때마다 서버는 받은 쿠키의 세션 ID를 DB에서 찾아야함. 따라서 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장해야 함. 유저가 늘어나면 DB 리소스가 더 필요함.

 

토큰 / JWT

토큰은 이상하게 생긴 문자열. 서버에 세션 ID 대신 토큰을 보냄. 서버는 DB에서 해당 토큰과 일치하는 유저를 찾음. 세션과 같은 방식.

JWT는 토큰 형식. JWT로 유저 인증을 처리하면 서버는 세션 DB를 가질 필요 없고, DB에서 유저를 찾는 번거로운 일을 하지 않아도 됨.

1. 유저가 정보를 바르게 입력해서 로그인되면, 서버는 DB에 뭔가를 생성하는 게 아니라 유저의 ID를 '사인'하여 문자열로 보냄. 이게 JWT 토큰.
2. 브라우저는 요청할 때 JWT 토큰을 서버에 보냄.
3. 서버는 받은 JWT 토큰의 사인이 유효한지 체크함. 조작되지 않았는지.
4. 유효할 때 유저로 인증함.

 

비교

세션 : 세션 ID만 갖고 있음. 세션의 정보는 서버의 세션 DB에 저장되어있음.

 

참고

• 노마드코더 - 세션 vs 토큰 vs 쿠키? 기초개념 잡아드림. 10분 순삭! https://youtu.be/tosLBcAX1vk