쿠키, 세션, 토큰, 캐시 자주 듣고 항상 개발때 사용하지만 정확히 각각의 차이를 매번 까먹고 찾아보게 되는데 쉽고 이해하기 쉽게 예를 들어 정리해보자!!
https://www.youtube.com/watch?v=gA1KsJ2ak10
우테코에서 만든 발표영상인데 굉장히 친절히 잘 설명되어있다!
쿠키
스터디카페에 들어가면 쿠키라는 책을 준다.
쿠키를 이용하면 스터디 자리를 정하거나 좋은 자리를 메모하거나 자리를 예약할 수 있다.
자기가 직접 다니고 다니기 때문에 자기 자신이 직접 수정이 가능하다.
즉 사용자가 사이트에 방문하면 데이터를 저장하는 것이 중요하다
하지만!!!
사용자가 모든 데이터를 수정할 수 있는 권한이 주어지면 문제가 발생할 수 있다.
ex) 스터디 자리를 다 취소하거나, 가격을 조정하거나, 이용권을 늘리거나 등등
따라서 수정 불가능한 중요한 정보들은 쿠키에 저장하기에는 부적절!!!
세션
중요한 정보는 세션에서 관리한다. 세션은 관리자가가 직접 관리하고 사용자는 데이터를 수정할 수 없다.
그렇다면 세션에서 누가 누군지 사용자를 식별 할 수 있을까??
사용자가 접근하면 관리자는 세션ID라는 임시 키를 발급해준다.
사용자는 이 임시키로 관리자 요청이 필요하면 이 세션ID를 함께 보내준다.
관리자는 이 세션ID를 보고 사용자를 식별한다.
근데 이 세션이 다 날라가버렸따????? 식별이 불가능하다. 대체방법이 없을까?
토큰
스터디 카페에 입장시 모든 사용자에게 토큰이라는 입장권을 줌
이 토큰에는 어떤 데이터를 가지고 있는지, 어떤 의미인지 알 수 없다.
그렇다면 이 토큰을 어떻게 사용할 수 있을까?
관리자는 특정한 비밀키를 가지고 토큰을 발급할 수 있다.
발급된 토큰은 사용자가 가진다.
관리자에게 요청이 필요하면 토큰을 관리자에게 전달한다.
관리자는 비밀키를 가지고 decoding을 진행
토큰을 디코딩해 토큰의 유효성과 데이터를 판별해 사용자를 식별한다.
그렇다면 사용자가 토큰을 가지고 있으니 조작 할 수 있지 않을까??
임의로 수정한 토큰을 관리자에게 보내도 정상적인 방식이 아니기 때문에 비밀 키로 해독이 불가능
토큰 해독이 불가능 하기때문에 사용자의 접근을 막아버린다.
토큰의 한계점
한 아이디로 여러 사용자가 서비스에 접근했을 때 이 토큰이 유효하기만 하면 사용자가 같은 아이디로 들어오더라도 접근 허용해준다.
하지만 세션이라면??
이미 접속한 적 있는 아이디로 다시 접속 시 접속을 막거나 관리함
캐시
가져오는데 비용이 드는 데이터를 임시로 저장해서 필요할 때 꺼내서 쓸 수 있게 해주는 것이 캐시
각각의 키워드들의 특징!!
- 쿠키 : 사용자에 의해 조작되어도 크게 문제되지 않는 정보를 브라우저에 저장
- 세션 : 인증에 대한 정보를 서버가 저장
- 토큰 : 인증에 대한 정보를 사용자가 저장
- 캐시 : 한 번 정송 받은 데이터를 저장해 놨다가 필요할 때 꺼내 쓰기 가능
(JPA에서 영속성컨텍스트랑 비슷한 느낌)
