JWT

쿠키

클라이언트가 웹 사이트에 접속할 때 서버가 클라이언트에 남기는 작은 데이터 조각입니다. 저장하고자 하는 정보를 response header에 저장하여 전달하며, key value 형식의 문자열로 구성되어 있습니다.

동일한 동작을 반복하지 않기 위해, 자주 요청해야 하는 데이터를 쿠키라는 작은 데이터 조작에 담아 웹 브라우저에 저장시켜 놓은 것이죠.

쿠키의 한계

쿠키는 클라이언트 즉, 각 사용자의 웹 브라우저에 저장되는 정보이기 때문에, 민감한 개인 정보 등은 저장하면 안됩니다. 노출 및 조작의 가능성이 있기 때문이죠. 또한 4KB 라는 사이즈 제한이 있기도 합니다.

따라서 주로 '팝업 다시보지 않기', '웹 페이지 개인 설정' 등 노출되어도 별 문제가 없는 사소하지만 자주 요청하는 데이터를 쿠키에 사용하는 것이 적합합니다.

세션

쿠키의 한계를 보완하기 위해 나온 것이 세션입니다. 아이디, 비밀번호 같은 민감 정보를 다뤄야 하는 로그인 같은 상황에서, 기존의 쿠키는 정보를 클라이언트에 저장했습니다. 하지만 세션은 서버의 세션 저장소에 데이터를 저장하고, 클라이언트에게는 사용자를 식별할 수 있는 세션 ID를 만들어 쿠키로 전달합니다.

그러면 이후에 반복적인 사용자 인증이 필요할때마다 이 세션 ID를 쿠키에 담아 서버에 전달하면, 서버가 ID를 통해 세션 저장소에 있는 정보와 비교하여 사용자를 식별하고 인증하는 것입니다. 이때 인증되지 못하면 401 에러를 반환합니다.

실제 로그인 데이터는 서버에 저장되어 있고, 사용자를 식별할 수 있는 값만 클라이언트에게 주기 때문에 보다 보안에 유리하게 되었습니다.

하지만 생성된 세션 ID 자체가 노출된 경우에는, 서버의 세션 저장소를 전부 지워서 서버에 나쁜 의도로 접근하는 인증 수단 자체를 없애버리는 방법이 있습니다.

세션의 한계

서버에 세션 저장소를 통해 데이터를 저장해야 하기 때문에 별도의 유지관리 비용이 들고, 사용자가 많아지면 메모리의 한계가 생깁니다. 또한 stateful한 특성 때문에 http의 장점을 발휘하기 어렵고 scale out에 방해가 됩니다.

JWT(Json Web Token)

JWT는 더 나은 인증 방식을 위해 탄생했습니다. 인증에 필요한 정보들을 Token에 담아 암호화시켜서 사용하는 것입니다. JWT의 구조는 다음과 같습니다.

1. Header : 토큰의 타입, 서명 생성에 사용된 알고리즘에 대한 정보가 담겨있습니다.
2. Payload : 토큰에 대한 property를 key-value 형태로 저장시킵니다.
3. Signature : 암호화되어 있는 서명입니다.

클라이언트가 요청을 보내면서 JWT를 함께 전달하면, 서버는 가지고 있는 개인키를 통해 암호화된 signature를 복호화합니다. 개인키는 서버에서만 유일하게 가지고 있습니다. 그리고나서 header값과 payload의 내용이 일치하는지 확인하고 인증을 허용하게 됩니다.

웹 스토리지

웹 브라우저에서는 key-value 데이터를 쿠키보다 더 직관적으로 저장할 수 있는 방법으로 '웹 스토리지'를 제공합니다.

session storage는 각 독립적인 저장 공간을 각 출처마다 제공합니다. 다만 브라우저 탭이 열려있는 동안에만 유지되고, 탭이 닫히면 삭제됩니다. 그리고 쿠키(4KB)보다 큰 저장공간(5MB)을 가지고 있습니다. 주로 잠깐 동안만 유지할 필요가 있는 입력 폼의 정보나 비로그인 장바구니 기능에 주로 사용합니다.

local storage는 브라우저를 닫고 다시 열어도 데이터가 유지됩니다. 별도의 유효기간 없이 데이터를 저장할 수 있고, 사용자가 삭제해야만 지워질 수 있습니다. 주로 자동 로그인 같은 반영구적으로 사용하는 기능에 이용합니다.

Web Storage API
JWT(Json Web Token) 알아가기