Cookie vs Session vs JWT

보통 서버가 클라이언트 인증을 확인하는 방법은 대표적으로
Cookie, Session, JWT 3가지 방법이 있습니다.

Cookie , Session, JWT의 작동 방식과 단점들을 살펴보고 요즘 트렌드인 JWT 가 어떤 부분이 좋은지 알아봅시다.

 

Cookie

쿠키는 웹 브라우저에 저장되는 작은 데이터 조각으로, 클라이언트와 서버 간의 상태를 유지하거나 정보를 저장하는 데 사용합니다.

쿠니는 주로 사용자 인증, 세션 관리, 사용자 환경설정 등 다양한 부분에서 활용됩니다.

 

쿠키의 작동 방식

1. 브라우저(클라이언트) 가 서버에 요청(접속)을 보냅니다.
2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 set-cookie에 담습니다.
3. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie 에 담아 보냅니다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광로를 띄우거나 합니다.

 

 

Cookie 방식의 단점

가장 큰 단점은 보안에 취약하다는 점입니다.

 

🐬 요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 당할 위험이 존재합니다.
🐬 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없습니다.
🐬 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능합니다.
🐬 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해집니다.

 

그래서 쿠키는 주로 사이트에 접속하자마자 알려주고 싶은 팝업 창이나 장바구니 등에서 이용합니다.

Session

이러한 쿠키의 보안적인 이슈 때문에, 세션은 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리합니다. 서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 합니다.

세션 작동 방식

1. 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다. 이때, 세션을 식별하기 위한 Session ID를 기준으로 정보를 저장합니다.
2. 로그인이 성공하면 서버에서 클라이언트로 Session ID 를 보내 주고 클라이언트는 쿠키에다가 Session ID 를 저장합니다.
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session ID를 쿠키에 담아 전송합니다.
4. 서버는 클라이언트가 보낸 Session ID와 서버 메모리로 관리하고 있는 Session ID를 비교하여 같다면 인증을 수행합니다.

Session 방식의 단점

🐬 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않습니다만 해커가 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재합니다.

🐬 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해집니다.

JWT

JWT는 "JSON Web Token"의 약자로, 웹 애플리케이션과 서비스 간에 정보를 안전하게 전송하기 위한 표준화된 방법입니다.
JWT는 JSON으로 인코딩 된 데이터를 사용하여 페이로드로 정보를 저장하고, 이를 서명하여 안전한 형태로 전송합니다. 주로 사용자 인증 및 권한 부여를 위해 사용됩니다.

🙎‍♂️ : " 페이로드가 뭐야? 서명은 또 무슨 말인데?? "
🙎‍♀️ " 차근차근 설명해 줄게 "

 

 

편지를 예를 들어 설명하자면 위에 이미지를 보면 편지는 3개의 요소가 있습니다. 여러 정보가 적혀있는 봉투, 실제 내용에 담겨 있는 편지지, 누가 쓴 글인지 확인시켜 주는 서명이 있습니다. jwt는 이 편지와 똑같은 역할을 하는 디지털 도구입니다. jwt에서는 내용을 payload라고 합니다. payload의 각 부분을 claim이라고 합니다 claim이란 주장이란 뜻인데 왜 주장이라고 부를까요?
그 이유는 페이로드의 내용을 곧 이 곧대로 믿으면 안 되기 때문입니다. 이 주장을 믿을 수 있는 방법이 필요합니다. 그것이 바로 서명입니다.
이 서명만 있으면 이 내용의 무결성을 단박에 알아볼 수 있습니다. 그런데 세상에는 다양한 서명방법이 있습니다. jwt는 서명방법을 강제하지 않습니다. 이걸 방지하기 위해서 base64로 인코딩 을 합니다. 이걸 마침표로 연결합니다.

 

 

그렇게 해서 만들어진 이 텍스트가 바로 jwt가 되는 것입니다. 이것이 jwt가 만들어지는 과정입니다.

더 자세히

두 사람이 있다고 가정해 보겠습니다. 오른쪽 사람이 왼쪽 사람에게 언제든지 찾아오면 1달러를 주겠다고 계약을 했다고 쳐봅시다.
이 계약을 본인이 했다고 증명하는 방법이 바로 서명이죠. 이제 계약의 내용과 함께 서명을 첨부해서 상대방에게 건네주면 나중에 계약서를 봐도 자신이 쓴 내용이라는 것을 확신할 수 있게 됩니다.

JWT 작동 방식도 이것과 비슷합니다. server 은 디지털 서명을 하기 위해서는 우선 비밀번호가 있어야 합니다. secret key라고 합니다. 그리고 내용이 있어야 하겠죠. 페이로드입니다. 또 서명을 하는 여러 알고리즘이 있습니다.
그중에 우리는 hmac이라는 것을 쓴다고 가정해 봅시다. hmac은 서명 생성기입니다. 페이로드와 secret key를 hmac의 입력으로 넣으면 그에 맞는 서명 이 생성됩니다. 결국 이렇게 만들어진 payload, signature, HMAC header을 조합해서 위에서 설명한 마침표로 연결한 정보를 client에게 전달합니다.

client는 JWT를 통해 인증을 해야 할 때 server로 내용을 전달합니다. server는 그것이 자신이 만든 내용이라는 것을 어떻게 확신할 수 있을까요?? 우선 header를 보니까 hmac으로 만든 서명이라고 하네요 페이로드와 secret key를 hmac에 입력합니다. 그럼 서명이 만들어지겠죠. 이 서명이 왼쪽이 준 서명과 일치한다면 이 페이로드는 오른쪽이 만든 것이 틀림없습니다. secret key를 가지고 있는 것은 오른쪽뿐이니까요. 이것이 서명의 원리입니다.

 

JWT의 장점

🍎 간편한 구현: JWT는 간단한 구조를 가지고 있어 구현하기 쉽습니다.
🍎 상태 없음(Stateless): 서버가 토큰을 발행하고 클라이언트가 이를 저장하고 전송하므로, 서버에 상태를 저장할 필요가 없어집니다.
🍎 보안: 서명된 토큰을 사용하여 데이터의 무결성을 검증하므로, 토큰의 변조를 방지할 수 있습니다.

JWT 의 단점

🍏 토큰의 크기: 페이로드에 포함되는 정보가 많을수록 토큰의 크기가 증가하며, 이는 네트워크 전송 속도를 느리게 할 수 있습니다.
🍏 보안 취약점: JWT는 서버의 비밀 키가 유출되면 보안이 손상될 수 있습니다.
🍏 재발급, 폐기의 어려움: 한 번 발급된 JWT는 만료되거나 폐기되기 전까지 유효하며, 재발급이나 폐기에 대한 관리가 어려울 수 있습니다.
🍏 정보 수정의 어려움: 한 번 발급된 토큰은 그 내용을 수정할 수 없으므로, 클라이언트 측에서 토큰을 변경할 수 없습니다. 이는 토큰의 보안성을 높이지만, 일부 상황에서는 유연성이 떨어질 수 있습니다.

 

 

요즘 많은 개발자분들이 JWT 인증 방식을 도입하고 사용하는 추세라고 생각합니다. 

저도 JWT 가 뭔가 설명할 수 없을 매력이 있다고 생각하기 때문에 사용하고 있고 최근에 나온 기술이 JWT 이기 때문에 사용해 보시는 것도 나쁘지 않다고 생각합니다. 사용법은 다른 블로그들을 참고하거나 제 블로그를 참고하시면 좋을 것 같습니다 .