HTTP : Cookie / Session / Token

HTTP 프로토콜의 Stateless를 보완하기 위해 사용하는 방법 :
。HTTP는 Stateless Protocol이므로, Server와 Client 간 HTTP Transaction 후 TCP Connection을 종료하면 상태정보를 유지하지 않는다.
▶ 통신이 끊어지면 상태정보가 유지되지 않으므로, 이를 보완하기위해 HTTP는 Cookie를 활용하여 Session , Token를 사용하여 상태정보 유지

쿠키 ( cookie ) :
。Stateless Protocol을 보완하고자 HTTP Server에서 특정 HTTP Client의 HTTP Transaction의 History를 조회할 수 있는 수단으로 활용하는 저장용 파일
▶ 만료기간이 존재하는 4kb 용량제한이 존재하는 key-value 저장소.
▶ 브라우저는 Session ID 또는 JWT Token을 포함한 쿠키를 저장 및 관리

Cookie cookie = new Cookie("custom-cookie", "custom-val");// 쿠키명, 쿠키값
cookie.setMaxAge(60*60); // 쿠키는 토큰, 세션 정보를 포함하므로 수명을 지정. : 초단위
cookie.setPath("/"); // 쿠키가 유효한 경로를 지정

。HTTP는 Stateless하여 HTTP Request는 요청한 사용자 정보에 대한 State를 포함하지 않으므로, 브라우저의 식별 데이터를 포함한 Cookie를 HTTP Request의 헤더에 포함하여 HTTP Server로 전송함으로써 HTTP Server 측에서 사용자의 신원을 파악
▶ HTTP Server는 각각의 브라우저에 할당한 식별용 데이터를 서버 백엔드 DB를 통해 인덱싱함으로써 특정 브라우저의 History을 조회

。쿠키는 Token / Session 을 통한 인증 시 서버 / 클라이언트 간 식별용 데이터를 포함하여 송수신하는 역할을 수행
▶ HTTP Server가 아닌, 브라우저에 쿠키를 저장하므로 민감한 사용자 정보를 쿠키에 포함하지 않고, 오직 식별 용도의 데이터( Session ID, JWT 토큰 )를 쿠키에 저장하여 송수신
▶ 보안이 취약한 특성으로 서버로 부터 접속한 브라우저를 식별하는 용도로 활용
ex ) 사용자 정보는 Session으로서 Server-Side의 세션 저장소에 저장하고, Cookie는 세션 식별 용도의 Session id만 송수신하는 역할을 수행

。브라우저의 Cookie File에 식별용 데이터를 저장 후 장시간이 지난 이후에도 브라우저에서 식별용 데이터를 포함하여 HTTP Request 하는 경우 HTTP Server의 백엔드 DB에서 삭제하지 않는 한 여전히 브라우저에 대한 정보를 유지할 수 있다.

• Cookie의 주요용도

  • User Session State
    。사용자의 로그인 정보 유지를 위한 Session id 또는 JWT Token를 각 HTTP 요청 / 응답마다 자동으로 헤더에 포함하면서 송수신
    ▶ Server에 로그인 시 HTTP Request에 Cookie Header Line를 포함하여 전송하면 사용자 세션 시간동안 브라우저를 HTTP Server가 식별하면서 로그인 유지
    
    
  • 장바구니
    。브라우저에 할당한 식별번호를 서버 백엔드 DB를 통해 인덱싱함으로써 브라우저에게 장바구니 등의 기능을 제공
    
    
  • Recommendation
    。식별번호에 해당하는 브라우저의 구매정보를 조회함으로써 상품 추천이 가능

• 
  
  
• Cookie 주요요소

  • HTTP Response Message의 HTTP Header의 Cookie Header Line
    。 Set-cookie : 쿠키식별데이터
    
    
  • HTTP Request Message의 HTTP Header의 Cookie Header Line
    。cookie : 쿠키식별데이터
    
    
  • HTTP Client의 브라우저에서 보관되는Cookie File
    。 Client Host의 State를 유지
    。HTTP Server에서 전송한 쿠키식별데이터를 Server Host Name과 함께 저장
    
    
  • HTTP Server의 백엔드 DB
    。식별번호로 브라우저의 History를 인덱싱

• 
  
  
• Cookie 원리
  。해당 과정은 단순히 쿠키 식별번호를 활용한 과정이며, 실무에서는 JWT 토큰 / Session id를 포함하여 송수신하는 용도로 사용됨
  
  。브라우저에서 초기 HTTP Server 접속 시 HTTP Server에서 해당 브라우저에 대한 식별번호를 할당 후 브라우저는 Cookie File에 해당 식별번호를 포함
  ▶ 이후 HTTP Request에 Cookie Header Line을 포함하여 HTTP Server에 전송 시 서버 백엔드 DB를 통해 식별번호를 인덱싱하여 해당 브라우저의 접속기록을 조회
  

  • 사용자가 Client의 웹브라우저를 통해 웹페이지를 요청하기위해 우선 Amazon 웹서버에 HTTP Request Message 전송
    。이때. 해당 웹브라우저로는 Amazon 웹서버에 처음 방문하고, Ebay 웹서버는 이미 방문한적이 있다고 가정
    
    
  • Amazon 웹서버에서 HTTP Request를 수신 시 송신한 브라우저에 대한 유일한 쿠키식별번호를 생성 및 백엔드 DB에 Entry 생성
    。해당 쿠키식별번호를 통해 차후 백엔드 DB에서 인덱싱을 수행
    
    
  • Amazon 웹서버에서 해당 식별번호를 HTTP Response Message에 HTTP Header로서 Set-cookie : 쿠키식별번호를 포함하여 해당하는 브라우저로 응답
    ex ) Set-cookie : 1678
    
    。Set-cookie : 서버에서 쿠키 / 세션을 생성 후 쿠키 / 세션ID를 브라우저로 전달 시 이를 포함하는 헤더
    ▶ 이후 해당 생성된 쿠키 / 세션ID는 cookie 헤더에 포함되어 통신됨
    
    
  • HTTP Response Message 수신 시 브라우저의 Cookie File에 Server Host name과 Set-cookie :쿠키식별번호를 추가
    。이를 통해 현재 브라우저는 Amazon 웹서버와 Ebay 웹서버의 Entry를 보유한 상태
    
    
  • 브라우저에서 해당 웹페이지를 요청하고자 HTTP Request Message의 헤더에 Cookie : 쿠키식별번호를 포함 후 Amazon 웹서버로 요청
    。브라우저는 Cookie File을 참조하여 Server에 대한 식별번호를 발췌 후 HTTP Request Message에 식별번호를 포함하는 Cookie를 포함
    
    
  • Amazon 웹서버에서 해당 식별번호를 백엔드 DB에서 인덱싱함으로써 해당 브라우저의 할도을 추적가능
    。Amazon의 경우 해당 식별번호에 해당하는 브라우저의 웹페이지 방문기록을 조회할 수 있고, 회원가입을 하지 않더라도 장바구니 등의 서비스를 제공가능

• 
  
  
• Cookie 종류

  • Session Cookie
    。만료시간(Expire data)를 설정 및 메모리에만 저장.
    。Browser 종료 시 Cookie를 삭제.
    
    
  • Persistent Cookie
    。장기간 유지되는 Cookie.
    。파일로 저장되어 Browser 종료와 관계없이 영속적으로 존재
    
    
  • Secure Cookie
    。HTTPS에서만 사용.
    。cookie 정보가 암호화되어 전송.
    
    
  • Third-Party Cookie
    。방문 domain 및 다른 domain의 cookie( ex. 광고 배너 )등을 관리 시 유입경로를 추적하기위해 사용.

세션 ( Http session )
。브라우저와 Server 간의 송수신 연결상태를 유지할 수 있는 방법
ex) 웹서버에 로그인 시, 새로고침하거나 브라우저를 닫았다 열어도 일정 기간은 로그인 유지되어있는데, 이처럼 연결상태 유지할수있게 하는 것이 Session

。HTTP는 세션을 구현하므로 로그인 인증을 유지하지만 FTP의 경우 세션을 구현하지 않으므로 매 요청마다 인증을 수행해야한다.

。서버에서 브라우저를 식별하기 위해 쿠키를 활용하여 Set-cookie / cookie 헤더에 Session ID를 포함하면서 HTTP 요청 / 응답을 수행하여 통신
▶ HTTP Session id를 식별자로 구별하여 접속한 Server의 Session Storage에서 세션을 식별

• 쿠키와 차이점?
  。Cookie는 식별용 데이터를 포함하여 브라우저에 저장 및 관리되지만, Session은 HTTP Server 측의 Session Storage에 저장하여 관리됨
  ▶ 브라우저에 쿠키를 저장하므로 민감한 사용자 정보를 쿠키에 포함하지 않고, 오직 식별 용도의 데이터만 쿠키에 포함
  
  。쿠키의 경우 단순히 식별용 데이터( Session ID 등 )를 송수신하여 서버에서 브라우저를 식별하고 로그인 상태를 유지하는 역할을 수행하지만, 세션은 사용자 정보를 Server Side의 세션 저장소에 저장되므로 로그인 인증 정보 등 민감한 정보를 관리하는 역할을 수행
  ▶ HTTP 요청 / 응답 시 cookie 헤더를 통해 Session ID만 송수신되고, 이를 통해 서버에서만 세션 저장소의 Session을 식별하여 활용하므로 보안이 우수.

  Http Session 절차 출처
  

  • HTTP Client가 HTTP Server에 Resource를 요청.
    
    
  • HTTP Server에서는 Http Request에 포함된 Cookie에서 Session id를 확인 후 없을 경우, 새로 발행한 Session을 세션 저장소에 저장 및 해당 세션의 Session id를 HTTP Response Message의 Cookie Header Line인 Set-Cookie 에 포함하여 응답
    。Set-cookie : 서버에서 쿠키 / 세션을 생성 후 쿠키 / 세션ID를 브라우저로 전달 시 이를 포함하는 헤더
    ▶ 이후 해당 생성된 쿠키 / 세션ID는 cookie 헤더에 포함되어 통신됨
    
    
  • Client는 브라우저에 수신한 Cookie에 포함된 Session id를 쿠키로 저장 및 Http Request Message의 Cookie Header Line에서 Session id를 포함하여 원하는 Resource를 요청
    
    
  • Server는 HTTP Request에 포함된 Session id를 통해 세션저장소에서 해당 Session을 찾은 후 상태정보를 유지하며 request에 대한 response를 전송.

토큰 ( token )
。Client-side에서 인증정보를 보관하는 방법.
▶ Server가 아닌, 인증정보를 client-side에 암호화하여 저장.

。Cookie에 토큰을 저장 및 송수신 함으로써 서버와 클라이언트간 요청 / 응답을 수행
▶ 클라이언트 브라우저에는 토큰을 쿠키로 저장 후 서버에 요청 시 토큰을 전송

。Session기반 인증방식은 Client에서 Server에 특정 User에 대한 정보를 요청할때마다 일일이 Session id의 일치여부를 확인.
▶ 매 요청마다 Server의 DB를 일일이 인덱싱 하는 것이 부담이되므로 Token 기반 인증방식이 등장하여 단순히 인즌 헤더에 포함된 토큰에 대해 해당 서버로부터의 발급여부와 유효여부에 대해서만 검증만 수행

• JSON 토큰 ( JWT : Json Web Token ) :
  。Web에서 Authentication과 정보교환 등을 수행하기위해 사용하는 Token 기반 인증 방식.
  。로그인 후 Server가 Client에게 발급하는 Token으로 활용
  ▶이후 Client에서 전송하는 HTTP Request마다 JWT를 포함하여 인증을 수행.
  
  。Client가 Token을 보관하면서 Stateless 특징을 지니므로, Session이 필요없다.
  ▶ 또한 Session처럼 DB 조회없이 token만으로 Authenticate가 가능.
  
  。JWT의 payload에 사용자 정보를 보관 가능.