: 일정기간동안 한 사용자의 상태를 유지시키는 것(클라이언트를 구분하는 수단).
특징
- 쿠키는 브라우저나 하드에 저장하는데, 세션은 서버에 저장한다.
- Session Id(유일한 값인 세션 키값. 개발자 도구에서 JSESSIONID)를 쿠키에 저장하고, 필요할 때마다 서버에 저장된 데이터를 이 키로 받아온다.
- 세션: HTTP 프로토콜에서 요청, 응답이 오고가면 연결이 끊어져 다음 요청이 어떤 사용자가 보낸지 모른다. 이 때 정보 유지를 위해 이 세션이라는 것이 필요하다.
JWT: 세션은 서버 처리를 필요로 하기 때문에 최근 JWT라는 토큰 기반 인증 방식을 많이 사용한다.
세션의 절차
- 클라이언트가 서버에 리소스 요청하면 HTTP 헤더의 쿠키에서 Session Id를 확인한다.
- Session Id가 없으면 Set-Cookie를 통해 새로 발행한 Session Id를 보낸다.
- 클라이언트는 세션 Id를 브라우저의 쿠키에 저장하고, 다시 리소스 요청 시 HTTP request 헤더에 Session Id를 포함하여 원하는 리소스를 요청한다.
- 서버는 클라이언트마다 구분이 되는 이 Session Id를 통해 세션을 찾아 클라이언트의 상태 정보를 파악하고 적절한 응답을 보내준다.
쿠키와 비교했을 때 세션의 장단점
장점
- 보안: 실제 세션정보는 서버에 저장하기 때문에 보안에 유리하다.
- 하나의 쿠키 당 4KB(=4096byte) 저장할 수 있는데, 세션을 사용하면 그냥 session Id만 부여해주고 세션 유지에 필요한 정보는 서버 리소스이기 때문에 제한은 없다.
단점
- 서버에 별도 저장 공간 필요하다. 서버 성능 저하의 요인이 될 수 있다.
- 세션 서버: LB 상황에서도 처리하기 어려운데, 이 때는 하나의 서버에 저장해 Sticky session 방식으로 통신하도록 구성하거나 세션서버로 Redis 같은 별도 서버를 둔다.
- CORS: 세션 관리 시 단일 도메인 및 서브 도메인에서만 작동하도록 되어있어, 여러 도메인에서 관리하는 것은 번거롭다고 한다.
- 클라이언트에 저장할 때 처럼 쿠키를 전부 보내진 않지만, 여전히 보안상 문제 있다.
보안상 문제: 하이재킹의 경우
: HTTP요청을 가로채, 사용자의 session id를 알아내면, 해커는 여전히 해당 session id로 session을 얻을 수 있음.
- 해결 방법 1. HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 얻기 어렵도록 하기 2. 세션에 유효기간을 주는 방법
Reference)
https://tansfil.tistory.com/58
https://velog.io/@junhok82/%EB%A1%9C%EA%B7%B8%EC%9D%B8%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9D%B4%EB%A3%A8%EC%96%B4%EC%A7%88%EA%B9%8CCookie-Session
https://hahahoho5915.tistory.com/32
https://interconnection.tistory.com/74
https://nesoy.github.io/articles/2017-03/Session-Cookie
https://tristan91.tistory.com/521