쿠키, 세션, 토큰 차이
쿠키
Key-Value 형식의 문자열 덩어리.
클라이언트의 브라우저에 설치되는 작은 기록 정보 파일임.
각 사용자의 브라우저마다 정보를 저장하니 고유 정보 식별이 가능함.
1. 클라가 서버에 요청 보냄.
2. 서버는 응답 헤더의 Set-Cookie에 저장할 정보를 담아서 보내줌
3. 이후 클라는 요청을 보낼때마다 저장된 쿠키를 헤더의 Cookie에 담에 보냄.
-> 이 정보를 바탕으로 누군지 식별 or 추천 광고를 띄움.
단점 :
1. 보안에 취약 , 유출 및 조작 가능.
2. 용량 제한 있음.
3. 브라우저마다 지원 형태가 달라서 브라우저간 공유 불가능
4. 쿠키 사이즈 커질수록 네트워크 부하 심해짐.
Session
보안때문에 -> 민감한 정보를 서버에 저장하고 관리
서버의 메모리 or 로컬파일/DB에 저장함.
Key : SessionID
Value: (생성시간, 마지막 접근시간, User 속성 등이 Map 형태로 저장됨)
인증 방식 :
1.유저가 웹사이트 로그인 하면 서버(메모리 or db)에 세션이 저장됨. (Session ID를 기준으로 저장)
2. 서버에서 브라우저에 쿠키로 Session ID를 저장함
3. 쿠키에 정보가 있기에 브라우저는 해당 사이트에 대한 모든 요청에 SessionID를 쿠키에 담음.
4. 서버는 클라가 보낸 SessionId와 서버 메모리로 관리하고있는 SessionID를 비교해 인증을 수행함.
단점 :
1. 해커가 SessionID 자체를 탈취하면 어떻게함 ?? -> 서버에서 IP특정을 통해 해결가능하긴함.
2. 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해짐.
Token 인증
클라가 서버에 접속하면, 서버에서 클라에게 인증되었다는 의미로 토큰을 부여함.
이 토큰은 유일하고, 발급받은 클라는 요청 보낼때 헤더에 토큰을 심어서 보냄.
그럼 서버에서는 클라에서 받은 토큰을 서버에서 제공한 토큰과의 일치여부를 체크해서 인증과정을 거침.
세션기반 : 서버가 파일or DB에 세션정보를 갖고있고, 조회하는 과정이 필요하기에 많은 오버헤드 발생.
BUT 토큰 : 정보가 클라에 저장 --> 메모리/스토리지 등을 통해 세션을 관리했던 서버 부담 덜 수 있음.
토큰 자체에 데이터가 들어있기에, 클라에서 받아 위조되었는지 판별만 하면 됨.
토큰은 앱과 서버가 통신/인증할때 가장 많이 사용됨.
이유 : 앱에는 쿠키/세션이 없기 때문임.
세션 : 클라의 상태를 계속 유지하고 사용 ( Stateful) -> 사용자 많아지면 성능 문제
토큰 : 상태 유지 X (StateLess) 함
단점 :
1. 토큰 자체의 데이터의 길이가 김 -> 인증 요청이 많아지면 네트워크 부하가 심해질 수 있음.
2. PayLoad 자체는 암호화되지 않기에 중요한 정보는 담을수 없음.
3,토큰 탈취 당하면 대처가 어려움. ( 그래서 사용 기간 제한을 설정함)
참고 :