1. 개요
회사에서 진행하는 프로젝트에서 jwt, csrf 토큰이 환경구성에 따라 달라지는지 알아보면서, 이에 대해 한번 정리할 필요가 있다는 생각으로 정리하였다.
첫번째 기록은 쿠키와 세션에 관한 내용이다.
2. 쿠키
클라이언트와 서버간의 통신은 기본적으로 stateless, 상태를 유지하지 않는다.
즉, 통신종료 후 상태정보를 유지하지 않고 끊어버리기에 상태정보를 저장하기 위해 세션과 쿠키를 사용하며 이것이 없다면 서로의 상태정보를 유지하지 않으므로 요청을 할 때마다 로그인을 해야 한다.
이에 대한 해결책으로 사용하는 도구가 쿠키이다.
일단 세션, jwt 모두 쿠키를 활용하는 만큼 쿠키를 먼저 알 필요가 있는데, 쉽게 말하면 인가내용을 쿠키에 저장하여 마치 입장티켓처럼 활용하는 의미로 볼 수 있겠다.
- 쿠키 : 클라이언트가 가지고 있는 key, value 형식의 상태 저장소.
- Request, 클라이언트의 요청 발생
- 서버 cookie 생성
- 서버가 클라이언트에 응답할때 HTTP Header에 쿠키정보를 포함
- 이 응답받은 쿠키 데이터를 클라이언트(브라우저)에 저장
- 이후 서버 요청 시 자신의 쿠키 정보를 포함하여 요청
쿠키는 브라우저가 종료되어도 유효기간을 명시하여 보존, 쿠키 생성 후 자동적으로 Request Header에 쿠키 정보를 포함하여 요청하므로 상태 정보를 전달할 수 있다.
서버에서 쿠키 업데이트가 필요할 경우 Response header에 업데이트 쿠키를 포함시키므로, 인가 정보를 바꾼다면 이와 관련한 캐싱 작업이 필요할 것이다.
2. 세션
쿠키가 클라이언트에 티켓을 보관한다면, 세션은 클라이언트가 아닌 서버에서 가지고 있으며, 티켓을 저장하는 저장소이자 상태 그 자체를 의미한다.
기본적으로 key value형식의 상태값을 sessionid로 표기하는데, 저장한 세션에 대해 sessionid를 발급하며 이를 클라이언트 쿠키에 저장한다.
- Request, 클라이언트의 요청 발생
- 로그인 등 클라이언트의 정보를 확인하였을때 Sessionid 생성, 서버는 클라이언트 별 고유한 session id 값을 생성한다.
- Session id, session data 저장, 클라이언트 식별값과 함께 세션 정보를 저장한다.
- 그 후 서버가 클라이언트에 응답 시 response header에 sessionid를 저장
- 클라이언트는 응답받은 sessionid를 자신의 쿠키에 저장
- 서버에 session(인가) 요청 시 자신의 session id를 포함한 정보를 전달하며, 서버는 전달받은 session id를 통해 서버 세션 데이터를 검색 및 인증한다.
- 응답할때 session 정보를 포함하여 응답한다.
세션은 서버에 데이터를 보관하므로 보안적인 면에서 유리하다 볼 수 있다. 하지만 그만큼 저장하는데 자원을 소모하므로 클라이언트가 많아진다면 누적해야 하는 데이터량이 많아져 부담이 가중된다.
3. jwt
이러한 메모리 점유에 대한 단점을 해결하기 위해 도입한 방안이 jwt, 토큰이다.
즉, 사용자가 로그인을 한 이후에 세션아이디 대신 토큰을 발급해준다.
이때 마찬가지로, 해당 토큰을 사용자가 쿠키로 저장해두고 서버에 요청할때마다 토큰값을 같이 전송하여, 자신이 인가된 사용자임을 보여주고 서버는 그 요청을 허가한다.
더이상 세션값을 서버에 저장할 필요가 없으니 서버 부하가 줄어든다. 위 세션에서 설명한 내용이 사실 jwt인데, 한번에 이해하려고 하기 보다는 분리해서 단계적으로 본다면 이해하는데 더 용이할 것이다.
여기게, jwt 토큰에 유효기간을 정하여 저장한다면 장기간 로그인 상태 유지로 인한 토큰정보 탈취를 방지할 수 있다.
