세션과 쿠키 그리고 토큰은 개발자라면 떼놓을수 없는 개념이다.
나도 이 개념을 확실히 하기 위해 정리해보려한다.
1. 쿠키
쿠키를 쓰는 이유에 대해 먼저 알아보자
그림처럼 홍길동으로 로그인 이후 , 그냥 /welcome으로 접속시 이미 브라우저와 서버가 요청-응답을 통해 주고받은 후 연결이 끊겼기 때문에 클라이언트가 홍길동인지 알지 못한다.
통신마다 url에 파라미터로 user 정보를 실는것은 보안상 심각한 결함이 있다.
해결책으로 나온것이 쿠키다.
cookie에는 set-cookie와 cookie 두개로 나눌수 있다.
브라우저가 요청시 요청 정보를 담은 쿠키를 서버가 response할때 set-cookie를 보낸다.
이제 set-cookie를 받은 브라우저가 쿠키저장소에 정보를 저장하고, 브라우저가 다음 요청부터 cookie를 찾아 꺼내서 보낸다.
쿠키의 특징으로는
- 헤더에 내용을 저장한다.
- 사용자 로그인 세션 관리 역할
- 네트워크 트래픽 추가 유발
- 최소한의 정보만 사용(세션 id,인증 토큰)
- (중요)보안에 민감한 데이터는 저장하면 안됨(주민번호,신용카드 번호 등등)
- 생명주기 설정가능. 만료 시 삭제 된다.
- 도메인에 따라 제한됨
2. 세션
세션도 쿠키와 같이 웹 통신을 유지하려는 것이다 (똑같이 stateless) . 역할에 있어서는 유사하나 특징에 있어서 많이 다르다.
클라이언트가 서버에 요청시 session id가 들어있는 쿠키를 요청하고, 서버는 서버 뒤의 세션 DB에서 session id를 확인할수 있다. 중요한것은 모든 정보가 브라우저가 아닌 웹 서버에 저장되는것이다 . 결국엔 이때 쿠키는 세션을 이용하기 위한 수단으로 이용된다.
세션과 쿠키를 비교했을때, 보안측면에선 세션이 훨씬 우세하다.
그렇다면 왜 세션말고 쿠키도 사용하는걸까?
세션은 서버를 이용하기 때문에 서버를 이용하는데 한계가 있고 속도 측면에서 쿠키를 이용하는것이 효율적으로 좋아서 병행하여 사용하는것이 웹사이트 이용 속도를 높일 수 있다. 하지만 세션에선 DB를 통해 id를 일일이 검색해야 하는 문제가 있다.(문제까지는 아니고.. 보안성을 높이기 위해 효율성이 떨어진다)
3. JWT토큰
Json Web Token 의 약자로 인터넷 표준 인증 방식중 하나다.
처음 로그인 요청시 서버가 비밀키를 통해 토큰을 클라이언트에게 발급해주고
클라이언트는 다음 요청부터 헤더에 jwt토큰을 실어 서버에 전달하면
서버는 서명 확인(유효성 검사)을 통해 사용자 정보를 확인한다.
주요 특징
- 토큰 사인을 통해 유효성 검사!
- 토큰자체가 인증된 정보이기에 별도의 인증 저장소(DB)가 필요하지 않다.
- 세션과 쿠키의 단점을 극복해내 현재 널리 쓰이는 방식이다.
- 쿠키와 다르게 정보를 담는 길이에 한계가 없다.
- 토큰은 암호화가 아니다!!
물론 JWT에도 한계점이 있다.
- payload가 암호화되지 않기 때문에 민감정보 저장 불가
- 토큰이 탈취당하면 만료될때까지 대처가 불가능하다.
- 전달량 자체가 많기 때문에 과도하게 이용시 부하 발생 가능
