TIL/Spring

TIL 2024-11-18 (Cookie/Session)

myoma 2024. 11. 18. 21:35

1) 학습한 내용

  • Cookie
  • Session

 


  • Cookie
    • 사용하는 이유
      1. HTTP는 Stateless, Connectionless 특성을 가지고 있다.
      2. Client가 재요청시 Server는 이전 요청에 대한 정보를 기억하지 못한다.
      3. 로그인과 같이 상태를 유지해야 하는 경우가 발생한다.
      4. Request에 사용자 정보를 포함하면 해결된다.
      5. 브라우저를 완전히 종료한 뒤 다시 열어도 사용자 정보가 유지되어야 한다.
    • 로그인 성공시 응답
      • set-Cookie
      • 로그인시 전달된 ID, Password로 User 테이블 조회하여 일치 여부 확인
      • 일치한다면 Set-Cookie를 활용해 Cookie에 사용할 값 저장
        • Cookie는 보안에 취약하다.
    •  로그인 이후 요청
      • 요청 헤더 Cookie : 사용자 정보
      • 로그인 이후에는 모든 요청마다 Request Header에 항상 Cookie 값을 담아서 요청한다.
        • 네트워크 트래픽이 추가적으로 발생한다.
        • 최소한의 정보만 사용해야한다.
      • Cookie에 담겨있는 값으로 인증/인가를 진행한다.
    • Cookie Header
      • Set-Cookie
        • Server에서 Client로 Cookie 전달(Response Header)
      • Cookie
        • Client가 Cookie를 저장하고 HTTP 요청시 Server로 전달(Request Header)
    • 생명주기
      • 세션 Cookie 
        • 만료 날짜를 생력하면 브라우저 완전 종료시 까지만 유지된다.
        • 브라우저를 완전 종료 후 다시 페이지를 방문했을 때 다시 로그인 해야한다.
    • 도메인
      • 쿠키가 아무 사이트에서나 생기고 동작하면 안된다.

 

 

 

  • Session
    • 서버에서 중요한 정보를 보관하여 로그인 연결을 유지하는 방법
    • Cookie의 단점 보안
    • 로그인 이후 요청
      • Client는 모든 요청에 Cookie의 SessionId를 전달한다.
      • 서버에서는 Cookie를 통해 전달된 SessionId 저장소를 조회
      • 로그인 시 저장하였던 Session 정보를 서버에서 사용
    • 특징
      1. Session을 사용하여 서버에서 민감한 정보들을 저장한다.
        • 예측이 불가능한 세션 ID를 사용하여 쿠키값을 변조해도 문제가 없다.
        • 세션 ID에 중요한 정보는 들어있지 않다.
        • 시간이 지나면 세션이 만료되도록 설정한다.
        • 해킹이 의심되는 경우 해당 세션을 제거하면 된다.
      2. Session은 특별한것이 아니라 단지 Cookie를 사용하여 클라이언트가 아닌 서버에서 데이터를 저장해두는 방법이다.
      3. Servlet은 Session을 자체적으로 지원한다.
    • @SessionAttribute
      • 이미 로그인이 완료된 사용자를 찾는 경우 즉, Session이 있는 경우에 사용한다.
    • Session의 한계
      • 서버가 DB 혹은 메모리에 저장된 세션 정보를 매번 조회하여 오버헤드가 발생.
      • 서버가 상태를 유지해야 하므로 사용자 수가 많아질수록 부담이 커진다.
      • Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증을 처리할 수 없다.
      • Scale Out(수평적 확장)에서 서버간 세션 공유가 어렵다.