쿠키, 세션, JWT

HTTP의 특징

HTTP 는 비연결성 ( Connectionless ), 무상태성 ( Stateless ) 의 특징을 갖고 있기 때문이다.

1. HTTP 프로토콜은 비연결성 ( Connectionless ) 프로토콜이라 클라이언트가 request를 보내고, 서버는 이에 대한 response를 보내면 연결이 끊어 진다.
2. HTTP 프로토콜은 무상태성 ( Stateless ) 프로토콜이라 request, response를 주고 받은 뒤, 상태 정보를 유지 하지 않은 채 통신이 끝난다.

이러한 특성을 보완 하기 위해서 쿠키와 세션이라는 방법이 존재 한다.

---

쿠키

• 쿠키란 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일이다.
• 사용자 인증이 유요한 시간을 명시할 수 있고 유효시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다.
• 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
• 클라이언트에 300개 까지 쿠키저장이 가능하고 하나의 도메인당 20개의 값만 가질 수 있다. 하나의 쿠키 값은 4KB까지 저장한다.
• Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
• 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송한다.

쿠키의 동작 방식

 

• (A) : 처음 사용자가 웹 사이트에 방문 하면 웹 서버는 사용자에 대해 아무것도 모른다
• (B) : 웹 서버는 사용자가 다시 왔을 때, 해당 사용자를 식별하기 위한 유일한 값을 쿠키에 할당한다. 그 리스트는 Set-cokie 또는 Set-cookie2 같은 HTTP 응답 헤더에 전달한다. ( 브라우저는 서버에서 받은 Set-cookie 헤더에 있는 쿠키 컨텐츠를 브라우저 쿠키 데이터베이스에 저장한다. ) 
• (C) : 사용자가 다시 같은 사이트를 방문하면, 브라우저는 서버가 이 사용자에게 할당했던 쿠키를 Cookie 요청 헤더에 기술해 전송한다

쿠키의 사용 예시

• 로그인창의 아이디를 자동완성
• 공지메세지를 하루 안보기 
• 쇼핑몰 사이트에서 로그인 안 한 상태로 물건을 장바구니에 담기
• 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?" 

즉 사용자의 편의를 위하되, 지워지거나 조작되거나 가로채이더라도 큰일이 없을 그런 수준의 정보들을 브라우저에 저장하는데 사용된다.

---

세션

• 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지 한다..
• 접속 시간에 제한을 두어 일정 시간 응답이 없을 경우 정보가 유지되지 않게 설정이 가능하다.
• 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
• 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
• 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID 이다.

세션의 동작

1. Request #1 에 요청이 들어왔다.
2. 서버에서는 세션을 시작하고, 세션에 'id' = 'mingoook' 이라는 값을 설정했다.
3. Response#1 에서의 Set-Cookie 헤더를 보면 쿠키때와는 다르게 이번에는 Session_id 가 있다.
4. 이제 클라이언트에서는 .test.com 도메인으로의 요청에는 session_id를 쿠키에 담아 전송한다.
5. 서버에서는 session_id를 가지고 해당 클라이언트의 세션을 찾아서 필요한 값을 조회한다. ( session_id는 서버가 클라이언트를 구분할 수 있게 해주는 key가 된다 )

세션의 사용 

• 사용자나 다른 누군가에게 노출되어서는 안되는 서비스 제공자가 직접 관리해야 할 정보들은 세션으로 서버 안에서 다뤄진다.

---

쿠키와 세션의 차이점

• 저장 위치
  • 쿠키 : 클라이언트
  • 세션 : 서버
• 보안
  • 쿠키 : 클라이언트에 저장되므로 보안에 취약하다
  • 세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋다.
• 라이프사이클
  • 쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다.
  • 세션 : 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다
• 속도
  • 쿠키 : 클라이언트에 저장되어서 서버에 요청 시 빠르다.
  • 세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느리다.

---

JWT ( Json Web Token ) 

JWT 는 토큰 기반 인증 방식으로 클라이언트의 세션 상태를 저장하는게 아니라 필요한 정보를 토큰에 담아서 클라이언트가 가지고 있다가 서버 요청시 담아서 사용한다.

서버는 요청이 들어오면 토큰을 검증하고 해당 요청을 처리한다

• 1. 클라이언트가 로그인을 위해 해당 정보를 서버에 전달한다.
• 2. 서버는 로그인 성공시 사용자 식별에 대한 정보를 Body에 담아 토큰을 발급하여 클라이언트에게 전달한다.
• 3. 클라이언트는 전달받은 토큰을 쿠키나 local / session strage에 저장하고 이후 서버에 요청시 해당 토큰을 담아서 전달한다.
• 4. 서버는 토큰을 검증 하고 해당 요청을 처리한다.

JWT 의 구성

1. 헤더 ( header ) : JWT 인 토큰의 유형이나 HMAC SHA256 또는 RSA와 같이 사용되는 해시 알고리즘이 무엇으로 사용했는지 등 정보가 담겨있다.
2. 내용 ( payload ) : 클라이언트에 대한 정보나 Meta Data 같은 내용이 들어있다.
3. 서명 ( signature ) : 헤더 ( header ) 에서 지정한 알고리즘과 시크릿 키, 서명으로 내용과 헤더를 담는다.

JWT 의 장단점

장점	단점
헤더(header)와 내용(payload)을 가지고 서명(signature)을 생성하므로 데이터 위변조를 막을 수 있다.	쿠키 / 세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
인증 정보에 대한 별도의 저장소가 필요없다.	내용(payload) 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
JWT는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.	토큰은 한번 발급 되면 유효기간이 만료될 때 계속 사용되어 탈취 당하게 되면 대처하기 힘들다.

JWT의 보안 전략

• 짧은 만료기한 설정 : 토큰의 만료 시간을 짧게 설정하여 토큰이 탈취되더라도 빠르게 만료되기 때문에 피해를 최소화 할 수 있다. 그러나 사용자가 자주 로그인 해야 하는 불편함이 있다.
• Refresh Token

클라이언트가 로그인 요청을 본면, 서버는 Access Token과 함께 긴 만료 기간을 가진 Refresh Token을 발급하는 전략을 취한다.

• 이후 Access Token이 만료되었을 때, Refresh Token을 사용하여 Access Token의 재발급을 요청한다.
• 서버는 DB에 저장된 Refresh Token과 클라이언트가 보낸 Refresh Token을 비교하여 유효한 경우 새로운 Access Token을 발급 해준다.

Refresh Token을 활용하면 Access Token의 만료 기한을 짧게 설정하면서, 사용자가 자주 로그인 할 필요가 없다. 또한 서버가 강제로 Refresh Token을 만료 시킬 수 있다.

---

참고 :

 

서버 인증. 쿠키(Cookie), 세션(Session), 토큰(JWT)

 

쿠키(Cookie)와 세션(Session)의 차이 (+캐시(Cache))

 

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

 

쿠키와 세션 개념

 

GitHub - NKLCWDT/cs: 🌈기술 면접 대비 및 지식 함양을 위한 Repo 입니다.