네트워크 원리에 대해 학습 중, 쿠키와 세션 그리고 토큰이 중요하다는 느낌이 와서 쓰는 글. 각자의 개념과 사용 이유, 동작 원리 그리고 어떻게 이루어져 있는지 알아보도록 하자!
쿠키
쿠키는 웹사이트 접속 시 브라우저에 저장되는 기록 정보 파일이다.
쿠키는 여러 요청이 동일한 브라우저에서 온 요청인지 서버가 식별하기 위해 사용된다.
Stateless 한 HTTP의 특성을 보완하기 위해 사용된다고 할 수 있겠다.
이를 통해 서버 및 웹사이트들은 쿠키를 보낸 해당 브라우저들에 필요한 정보를 더 신속하게 제공해줄 수 있다.
쿠키는 이름, 값, 만료 기간, 경로 및 도메인 등으로 이루어져 있다. 크롬에서 확인할 수 있다.
동작 원리는 다음과 같다.
- 클라이언트가 HTTP 요청을 한다.
- 서버가 HTTP 요청에 대한 응답 헤더에 쿠키를 붙여 보낸다.
- 브라우저는 받은 쿠키를 보관하고 이후 같은 웹사이트를 방문할 때 쿠키를 함께 전송한다.
- 서버는 쿠키를 보고 클라이언트에게 맞춤 정보를 제공한다.
- 쿠키는 요청/응답 간 수시로 업데이트된다.
- 쿠키는 만료 날짜에 따라 무효가 되지만, 사용자가 삭제하거나 웹서버가 삭제 요청하거나 브라우저에서 쿠키를 비활성화한다면 쿠키는 무효가 된다.
세션
세션은 클라이언트 식별 정보를 담고 있는 웹서버의 임시 저장소이다.
세션도 쿠키와 동일하게 클라이언트를 식별하기 위해 사용된다.
하지만 쿠키와 다르게 서버에 저장되기 때문에 보안상 더 안전하다.
세션은 세션 ID, 세션 데이터, 세션 만료 시간, 세션 유지 방법 등으로 구성되어 있다.
세션 ID는 클라이언트를 식별하기 위한 고유한 식별자이다.
세션 데이터는 서버가 유지하는 사용자 정보이다. 로그인 정보, 좋아요 한 게시물 목록 등이 해당한다.
마찬가지로 브라우저에서 확인할 수 있다.
동작 원리는 다음과 같다.
- 클라이언트가 HTTP 요청을 한다.
- 서버가 HTTP 요청한 클라이언트에게 고유한 세션 ID를 발급하여 쿠키에 저장, 응답과 함께 전송한다.
- 클라이언트는 이후 요청 시 세션 ID를 쿠키에 담아 서버에 전송한다.
- 서버는 쿠키에 담긴 세션 ID를 보고 클라이언트의 상태 정보를 유지한다.
- 클라이언트가 브라우저를 종료하거나 세션의 만료 기간이 도래하면 서버는 해당 클라이언트 세션 데이터를 삭제한다.
세션은 로그인 상태 유지 등을 구현하는 데 사용된다.
로그인한 후 새로고침하거나 다른 페이지로 이동해도 로그인이 유지된 이유는 클라이언트가 열심히 세션 ID를 담은 쿠키를 보내고 있었기 때문이었다.
JWT
JWT는 JSON Web Token의 약자로서, JSON 형태의 데이터를 사용한 토큰 기반 인증 방식이다.
JWT는 쿠키와 세션 인증 방식에서 발생할 수 있는 단점들을 극복한 인증 방식을 갖고 등장하였다.
JWT는 Header, Payload, Signature의 구조를 가지고 있고 각 구성요소는 점으로 구분되어 있다.
Header에는 토큰의 유형과 해싱 알고리즘이 명시되어 있다.
Payload에는 토큰에 포함될 정보가 저장되어 있다. 사용자 ID, 사용자 이름, JWT 발급 시간 등이 포함됨.
Signature에는 토큰의 유효성 검사를 위한 데이터이다. 이는 Header와 Payload를 합쳐 비밀키를 사용하여 해싱한 값이다.
jwt.io 라는 사이트에서 직관적으로 확인해볼 수 있다.
JWT 생성 원리
- Header에 알고리즘과 타입을 명시하여 생성한다.
- 클라이언트에게 받은 사용자 정보를 Payload에 담아 생성한다.
- Header 와 Payload를 합친 데이터를 암호화 알고리즘을 통해 Signature를 생성한다.
// 비밀 키를 넣어 HS256 알고리즘으로 Signature 생성.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
- Header . Payload . Signature 를 합쳐 JWT가 된다.
{Base64Url encoded header}.{Base64Url encoded payload}.{Base64Url encoded signature}
동작 원리
- 사용자가 인증을 시도하면 서버는 올바른 정보인지 확인한 후 JWT를 발급한다.
- JWT는 클라이언트에게 전달되고 클라이언트(브라우저)는 쿠키, 로컬 스토리지 등에 저장한다.
- 클라이언트가 서버에 요청할 때마다 JWT를 함께 보낸다.
- 서버는 JWT에 대한 유효성 검사 후 해당되는 응답을 클라이언트에 보낸다.
그런데 이 때, Access Token과 Refresh Token 개념이 등장한다.
Access Token & Refresh Token
서버가 토큰을 발급할 때 두 가지 토큰을 함께 발급하여 클라이언트로 제공해줄 수 있다.
Access Token은 사용자 인증에 성공했을 때 발급되며 서버에 요청시 인증 정보로 사용되는 토큰이다. 반면 Refresh Token은 Access Token의 만료 시점이 도래했을 때 새 Access Token을 발급받기 위한 용도로 사용된다.
주로 Access Token은 만료 기간을 짧게 설정하여 만료시 Refresh Token으로 재발급 받아 인증 정보를 유지하는 방식을 사용한다. 만약 Access Token이 탈취되더라도 Refresh Token으로 재발급하여 사용할 수 있기 떄문이다. 재발급되면 기존의 Access Token은 무효해진다.
JWT 보완하기
- HTTP를 통해 데이터를 암호화한다.
- 토큰 저장 방식 변경
- 보안 요소 추가
비교
쿠키
쿠키는 비교적 구현이 간단하고 모든 브라우저에서 지원되어 범용성이 높다.
하지만 브라우저에 저장되어 보안에 취약하고 저장할 수 있는 용량이 제한되며 도메인 단위로만 제한을 둘 수 있다는 단점이 있다.
세션
세션은 세션 정보가 서버에 저장되기 때문에 쿠키보다 보안에 강하고 용량이 더 커 많은 정보를 저장할 수 있다. 그러나 서버에 세션 정보를 저장하기 때문에 서버의 자원을 더 많이 소모하고 서버 확장시 세션을 활용할 추가 방안이 요구된다.
JWT
JWT는 암호화된 데이터를 통해 유효성을 검사하기 때문에 쿠키, 세션보다 더 보안에 유리하다. 또한 서버에서 사용자의 정보를 저장하지 않기 때문에 서버의 자원을 절약할 수 있다.
하지만 JWT는 탈취되었을 때 제 3자가 악용할 수 있기 때문에 이를 보완할 추가 방안이 필요하다.
마치며
쿠키, 세션, JWT를 학습하며 클라이언트의 정보를 저장하고 인증하는 방식들이 각자 어떤 구조로 어떻게 작동하는지 알 수 있었다.
모든 기술이 그렇듯 이 친구들도 필요한 상황에 맞추어 사용해야 함을 알 수 있었다.
쿠키는 좋아요 기능을 구현할 때 사용해보았는데 저런 방식으로 동작하는 줄은 모르고 있었다.
더 깊은 내용은 기술을 직접 사용할 때 알아보도록 하자.
그리고, 썸네일의 저 짤은 잘못된 것이었다. 쿠키는 브라우저가 구운 게 아니었다..
