쿠키(Cookie), 세션(Session), 토큰(Token) 인증

HTTP 특성

1. Connectionless(비연결성)

클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 연결을 끊어버리는 성질이다.

=> 데이터 유지되지 않는다.

2. Stateless(무상태)

서버는 클라이언트를 식별할 수 없다.

=> 상태를 기억하는 방법 : 쿠키, 세션, 토큰 인증 방식

---

쿠키(Cookie)

특성

• HTTP의 비연결성, 무상태 특성을 보완하기 위해 사용
• 클라이언트에 저장되는 Key-Value 형태의 데이터 파일
• 최대 300개까지 저장 가능, 유효 시간 존재, 도매인당 20개 값만 가질 수 있음, 4KB까지 저장 가능
• 클라이언트가 웹사이트 방문 시 브라우저에 전송
• 브라우저는 요청을 저장했다가 서버에 다시 전송하여 동일한 브라우저 요청이라는 것을 알려주고 사용자 인증 유지
• 사용자는 브라우저 설정 화면이나 개발자 도구에서 쿠키 확인, 수정, 삭제 가능
• 제 3자가 조회하는 것도 가능하기 때문에 개인 정보나 보안상 민감한 정보 저장 용도로는 적합하지 않음
• 사용자에 의해 조작되어도 크케 문제되지 않을 정보를 브라우저에 저장함으로써 웹사이트 이용을 편리하게 해주는 것

인증

1. 클라이언트가 자격 증명이 포함된 요청을 백엔드 서버로 전송
2. 서버는 자격 증명 검증하고, 성공 시 DB에 세션을 생성하고 쿠키 객체에 고유 ID를 포함하는 응답에 Set-Cookie 헤더 포함
3. 브라우저는 쿠키를 저장하고, 클라이언트는 로그인이 되어 있는 한 모든 요청에 쿠키를 담아 서버에 전송
4. 서버는 DB에 저장된 것과 쿠키에 저장된 세션 ID를 비교해 검증
5. 로그아웃 시 DB에서 쿠키 삭제

장점

• stateful한 상태로 만들 수 있고, 사용자의 상태정보를 추적하기 용이함
• 쿠키의 사이즈가 작아 클라이언트 측에서 정보를 저장하기 부담 없음
• HTTP 전용이기 때문에 클라이언트 측에서 읽을 수 없음 => Cross-site-scripting(XSS) 공격에 안전함
• 요청에 자동적으로 포함되어 수동으로 구현할 필요가 적어 용이함

단점

• Cross-site request forgery attack(CSRF) 공격에 취약함
• DB에 세션 데이터를 저장하거나 서버 메모리에서 유지해야 함 -> 확장성 저하, 많은 유저들이 접속할 경우 오버헤드 증가
• 용량 제한이 있음
• 웹 브라우저마다 쿠키에 대한 지원 형태가 달라 브라우저간 공유 불가능

세션(Session)

특성

• 쿠키를 기반으로 하고 있지만, 데이터 파일을 서버에 저장
• 클라이언트가 서버에 요청을 보내면 클라이언트에게 고유한 세션 ID를 부여하며, 브라우저가 종료할 때까지 상태 유지
• 접속 제한 시간 설정 가능
• 일정 시간 응답이 없을 경우 세션이 해제되도록 설정 가능
• 서버 리소스 사용 -> 서버 성능에 많은 영향

인증

1. 유저가 로그인하면 세션이 서버 메모리 상에 저장됨. 세션 식별을 위한 Session ID 기준으로 정보 저장
2. 브라우저에 쿠키로 Session ID 저장
3. 브라우저는 해당 사이트에 대한 모든 요청에 Session ID를 쿠키에 담아 전송
4. 서버는 클라이언트가 보낸 Session ID와 서버 메모리로 관리하고 있는 Session ID 비교해 인증
5. 로그아웃 시 서버의 세션정보 삭제, 클라이언트 쿠키 갱신

장점

• 쿠키를 포함한 요청이 외부에 노출되더라도 Session ID 자체는 유의미한 개인정보를 의미하지 않음
• 각 사용자마다 고유한 Session ID 발급 -> 요청이 들어올 때마다 회원정보 확인 불필요
• 개발자가 구현하기 명확함

단점

• 세션 하이재킹 공격 가능 => HTTPS를 사용해 요청을 탈취해도 정보를 읽기 힘들게 하거나, 세션에 유효시간 부여 가능
• 멀티 디바이스 환경에서 로그인 시 구현 어려움
• 서버 메모리 부담
• Session ID를 해커가 가로채 클라이언트인 척 위장할 수 있음
• 서버에서 세션 저장소를 사용하기 때문에 요청이 많아지면 서버 부하 심화

---

쿠키 vs 세션

• 쿠키는 클라이언트, 세션은 서버에 저장
• 처리속도 : 쿠키 > 세션(서버에서 처리가 필요함)
• 쿠키는 변질되거나 전송 중 스니핑 되어 변조될 수 있으므로 보안상 취약, 세션은 서버에서 처리하기 때문에 보안성 좋음

---

토큰(Token)

특성

• 클라이언트에게 토큰을 부여하여, 인증 시 토큰 기반으로 사용자 인증을 수행
• JWT(JSON Web Token) 이용 -> 클라이언트와 서버 간 JSON 객체를 이용해 안전하게 전송

인증

1. 클라이언트 로그인 요청 시, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담음
2. 서버는 암호화된 비밀키를 이용해 JWT 토큰 생성 및 클라이언트에 전송
3. 클라이언트 브라우저는 로컬 스토리지, 세션 또는 쿠키를 이용해 토큰 저장
4. 이후 요청 시에 JWT는 Bearer에 의해 헤더 접두사에 인증 정보 추가, 서버는 응답 보내기 전 디코딩 된 토큰을 이용해 Signature 검증
5. 로그아웃 시 서버와 교류 없이 클라이언트 토큰 파기

장점

• 발급 후 검증만 하기 때문에 추가 저장소가 필요하지 않아 간편하고 서버 확장 및 유지보수에 유리
• 서버는 로그인 성공 시에 토큰에 서명하고 요청에 들어오는 토큰이 유효한지만 확인하면 됨
• 분산 시스템에서 확장성 우수
• 토큰 기반으로 다른 로그인 시스템에 접근 및 공유 가능
• JSON 기반이므로 REST API에서도 잘 동작함
• CORS가 활성화된 토큰 기반 인증 방식 사용 시 API를 다른 서비스 및 도메인에 쉽게 노출 가능 -> 웹 플랫폼과 모바일 플랫폼을 모두 지원할 수 있고 구현이 훨씬 쉬워 모바일과의 호환성이 좋음

단점

• JWT는 토큰의 길이가 길어, 인증 요청 많아질수록 네트워크 부하 심화
• Payload 자체는 암호화 되지 않음 -> 유저의 중요한 정보를 담을 수 없음
• 토큰을 따로 서버에 저장하지 않아 탈취당하면 추적 어려움
• 유효기간 반드시 설정해야 함
• 특정 사용자의 접속을 강제로 만료하기 어려움

---

[참고자료]

https://victorydntmd.tistory.com/m/286

[HTTP] HTTP 특성(비연결성, 무상태)과 구성요소 그리고 Restful API

https://velog.io/@jung5318/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

쿠키, 세션, 토큰의 차이점

https://devbirdfeet.tistory.com/m/203

Cookie(쿠키) / Cache(캐시) / Session(세션) / Token(토큰)

https://hongong.hanbit.co.kr/%EC%99%84%EB%B2%BD-%EC%A0%95%EB%A6%AC-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0-%EC%BA%90%EC%8B%9C-%EA%B7%B8%EB%A6%AC%EA%B3%A0-cdn/

완벽 정리! 쿠키, 세션, 토큰, 캐시 그리고 CDN

https://velog.io/@kingth/%EC%84%9C%EB%B2%84-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%84%B8%EC%85%98%EC%BF%A0%ED%82%A4-%ED%86%A0%ED%81%B0

서버 인증 방식(세션/쿠키, 토큰)

https://tofusand-dev.tistory.com/m/89#token-%EA%B8%B0%EB%B0%98-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D

Cookie, Session, Token 의 차이점

https://devyuseon.github.io/about%20dev/cookie-session-token/

Cookie vs Session vs Token(JWT)

https://it-techtree.tistory.com/m/entry/define-web-cookie-session-token

Web, Cookie, Session, Token 인증 정의 및 특징