JWT의 개념이 이게 맞나요?

Question

안녕하세요,세션관련 공부를 하다보면 기존의 세션방식 vs JWT 방식 의 차이에 대해 보게 됩니다.세션: 로그인 유지하고있는 사용자가 많을수록 메모리 점유JWT: 토큰이 유효한지 무효한지만 판단하므로 최소한을 제외한 추가적인 메모리 자원 소요가 없음그런데 지금까지 봐온 프로젝트를 보면 JWT를 세션처럼 사용하고 있는 곳이 많더라구요.메모리에 들고있는게 아니라 DB에 로그인정보를 넣는 방식이긴 하지만요.아예 중복로그인 방지 처리까지 들어가있습니다.인스턴스에 저장하든, DB에 저장하든 결국 이전의 session과 유사한 방식이라는 느낌을 받았습니다.예전처럼 사용자 정보 다 들고있을거면, 이럴거면 그냥 JSESSIONID나 PHPSESSIONID 쓰던 예전 방식이 더 쉽고 편한데,왜 굳이 요즘에는 JWT를? 라는 생각이 들었는데요 제가 모르는 JWT의 이점이 뭔가 더 있는걸까요?

기검기검 · Answer

MSA와 Rest api의 개념과 접목시키면 추가적인 이점들이 있긴합니다 :>

늦어도공부하자 · Answer

모놀로틱이 MSA로 바뀐 이유가 뭘까요?세션이 JWT로 바뀐 이유가 뭘까요?Restful API를 쓰게 된 이유가 뭘까요?

HJOW · Answer

어떤 데이터를 들고 있는지 여부보다 더더욱 중요한 차이가 있습니다.어디에 저장이 되는지입니다.세션의 경우는 실질 데이터들이 메모리 상에 저장이 됩니다. 서버의 메모리 상에 말이죠. 그리고 그 세션에 액세스하기 위해 필요한 키값만이 클라이언트 (사용자의 웹 브라우저) 쿠키에 저장이 됩니다. 그래서 사용자 수가 많고, 세션 안에 담기는 데이터가 많으면, 서버 메모리 사용량이 커질 수가 있습니다.JWT 토큰은 각 클라이언트 (사용자의 웹 브라우저) 의 스토리지나 쿠키에 저장을 합니다. 토큰 자체를 말이죠. https://velog.io/&#64;0307kwon/JWT%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-localStorage-vs-cookie 실질 데이터들 또한 토큰 안에 담겨있습니다. 다같이 클라이언트의 스토리지나 쿠키에 저장을 하게 됩니다. 그래서 서버와 통신할 때 헤더에다 토큰을 넣어주어야 하는 것이고 서버에서 이 토큰에서 값 꺼낼 때 매번 유효성 검사를 해야 하는 것이죠. (JWT토큰 자체 기능) 대신 서버의 메모리 사용량에 크게 지장이 가지는 않죠.

개발잡부 · Answer

관심사 분리죠MSA의 경우, 말씀하시는 세션을 인증서버 내에서만 관리한다면 다른서버에서는 토큰만 보면됩니다반면 세션방식으로 한다면 MSA의 모든서버가 세션을 바라보고 있어야합니다

기검기검 · Answer

일전에 제가 JWT를 도입했던 프로젝트에 JWT를 사용했던 이유에 대해 작성했었던 것입니다 참고바랍니다.

캐티 · Answer

공홈을 보면 무엇인지 알겠지 않나요.서버 세션에 데이터를 보관하지 않으므로 서버 리소스 절약에 이득이 생기고, 분산 처리를 하였을 때 어느 노드를 사용하여도 고유키만 안다면 동일한 인증 정보를 얻을 수 있어서 좋아요. 데이터가 넘모 길다는 문제가 있지만 말이어요. http 헤더 압축이 적용되면 특별한 문제가 없을 것으로 전망해요.[1] JSON Web Tokens - jwt.io

돈이좋아요 · Answer

JWT 도입 이유를 여쭤본게 아닌 것 같은데 다들 왜......JWT를 DB의 세션관리 테이블에 넣어놓고 관리하는 곳들이 있긴 합니다. 제가 봐온 곳들 중 대부분 refreshToken accessToken 구현을 안하고, 세션과 동일하게 쓰더군요.다른 곳에서 로그인하면 db의 jwt가 바뀌어버리니 기존 사용자를 로그아웃 시킬 수 있다면서....이처럼 특별한 이유가 있지 않는 이상, 그럴 이유는 없습니다.

Clickin · Answer

좋은 예시가 되련진 모르겠지만 현실에 빗대어보겠습니다. 더 잘 아시는 분들이 첨삭해주시면 감사합니다.세션은 주민등록번호와 비슷하고 JWT는 여권과 비슷합니다.국내(=한 서버 내)에서는 주민등록번호(=세션ID)만 있으면 신분 증명이 다 됩니다. ※도용은 생각하지 않도록 합시다.중앙정부(=서버)에서 국민의 정보를 다 가지고 있으니 각 관공서에서는 주민의 정보를 가지고 있을 필요가 없고 주민번호로 중앙정부에서 조회하면 원하는 정보는 다 얻을 수 있습니다.하지만 외국(=다른 도메인 혹은 다른 서버)으로 나가면 한국 중앙정부에 접속하는건 어렵습니다. 전 세계 모든 국가의 정부의 양식에 맞춰서 통신하기도 불가능에 가깝죠그래서 신분을 증명할 정보와 개인의 신상을 적어둔 여권(=JWT)을 발급해서 인증합니다.하지만 위조여권을 만드는 경우가 잦아져 각 국가에서는 공동 협약을 맺고 여권이 위조되지 않았는지를 검증하는 시스템(=유효성 검사)을 만들기로 합니다.이걸로 위조 검증만 통과하면 여권에 적힌 정보를 믿을 수 있으니 여권 소지자의 개인정보를 굳이 타국 정부에 접속해서 가져올 필요가 없어졌습니다.국가간 네트워크 속도가 느리거나 직통 네트워크가 없어서 개인정보를 가져오는데 어려움이 있으면 이런 방식이 효율적이겠죠.

ykd · Answer

생각하신대로 jwt 자체는 평문으로 보이기 때문에 민감정보를 페이로드에 담을 수 없습니다.단순 식별자만을 페이로드에 실어나르는 용도라면 세션과 차이는 크게 없어지는 것이 맞죠..자체 expire 가능, 페이로드에 자체적인 부가정보를 포함할 수 있음, ... 등의 범용성 때문에 많이들 사용하지 않을까 합니다

장독깨기 · Answer

특정 서비스를 하는 서버가 있습니다. 이 서버는 인증을 요구합니다.이 서버에 서비스를 요청하는 여러 클라이언트들이 있을 수 있습니다.모바일 앱, 윈도우용 앱, 다른 서버 등이 있을 수 있습니다.이들 클라이언트들이 서버에 인증을 받는 방법이 있어야 하는데요,이를 표준화 한 것이 있습니다. oauth 입니다.oauth 는 기본적으로 토큰을 베이스로 인증을 처리합니다.자세한건 oauth 규격이나 관련 자료를 참조하면 될 것 입니다.뭐 암튼, 이 토큰의 한 종류가 jwt 입니다.기존 다른 방식의 토큰은 데이터베이스에 저장을 하고, 클라이언트 요청이 있을 때 이를 검증합니다.그런데, jwt 는 디코딩을 해서 그 내용을 알 수 있습니다. 즉, 검증을 위해 데이터베이스에 접속할 필요가 없으니, 성능 상 유리한 부분이 있습니다.이 부분이 jwt 의 목적이고 이점입니다.그런데, ... 뭐 암튼 그렇습니다. ㅎhttp 는 stateless 입니다.따라서, 브라우저가 요청할 때 WAS 서버는 접속 브라우저가 누구인지 알 수가 없습니다.그래서, WAS 는 브라우저 최초 접속 시 WAS 내 메모리에 영역을 할당하고, 이 영역에 아이디를 부여해서 브라우저 쿠키에 저장합니다. 이게 세션이죠.그럼, WAS 는 접속 브라우저가 누구인지 쿠키에 담긴 세션 아이디로 구분할 수 있습니다.이 세션에 우리는 사용자 정보를 담아 인증 처리를 할 수 있는거죠.즉, 세션 방식은 접속 클라이언트가 브라우저 일 때만 유효합니다.브라우저 외의 클라이언트는 당연히 토큰 방식을 이용해서 인증 처리를 해야겠죠.이렇게 토큰 방식과 세션 방식은 목적이 다릅니다. 무엇이 낫고 이점이 있고 이런 부분이 아닙니다.다만, 토큰 방식을 이용하면 분산 시스템이나 SSO 등 어려 분야에서 통합 인증을 하는데 좀 더 편리하게 구현할 수 있습니다.단순히 웹 환경에서 웹 페이지를 서비스 한다면 굳이 JWT를 사용할 필요 없습니다.리액트로 SPA 를 작성하고 프런트를 백앤드 서버와 분리한다면 JWT를 사용해야 할 것 입니다.상황에 맞게 사용하면 될 것 입니다. :)

Rphi · Answer

경우의 수를 나눠보면 좋을 것 같은데순수하게 jwt만 사용Jwt + 발급 정보를 세션에 저장Jwt 자체를 세션처럼 따로 저장(아마 본문 케이스일듯)1번의 경우는 아마 잘 아시겠지만 stateless를 위한 설정이죠. 메모리나 DB 저장이 필요 없지만 악의적인 사용에 대한 revoke가 불가능하다는 단점이 있습니다.2번의 경우는 jwt를 발급하되 해당 발급 정보를 따로 세션에 저장하는 방식입니다. 세션을 사용하기 때문에 상태 정보를 저장할 공간이 필요하지만 어쨌든 세션 자체를 사용하는 것에 비해서는 덜 사용하죠. 사용자가 필요한 정보를 대부분 들고 있으므로 트래픽도 절감할 수 있고, 필요하다면 토큰에 대한 revoke도 할 수 있어서 어떻게 보면 중간이라고 할 수 있겠네요. Spring Authorization Server에서 이 방식을 사용합니다.3번 방식은 아마 아시겠지만 별로 좋지는 않은 방식입니다. Http 통신 도중 변조되지 말라고 암호화를 걸어놓은 건데 그걸 굳이 db에 그대로 저장하는 의미가 없죠. 그래도 굳이 따지자면 트래픽이 많지 않으면 큰 문제는 없고.. 어쨌든 revoke는 가능하겠군요 ㅎㅎ

dujulgi · Answer

스케일아웃이 가능하려면 어플리케이션이 Stateless 해야하는데 redis같은 세션서버 안쓴다면 jwt써야죠

wharup · Answer

JWT 같은 토큰으로 로그인 세션을 관리하는 방식은 확장이 쉽고 단일 장애 지점이 없어지는 큰 장점이 있습니다.그런데 로그아웃을 해도 토큰을 폐기 할 수 없는 단점도 있어 보안이 중요한 곳에는 그대로 사용이 어렵습니다.그걸 보완하기 위해 토큰을 DB나 Redis등에 저장해서 토큰의 유효성을 관리하기도 하는데그러면 토큰의 장점이 많이 희석되서, 애초에 왜 토큰을 사용했는 가에 대한 의문이 들 수 있습니다.세부 구현 방식에 따라 여전히 장점을 가져갈 수도 있긴 합니다.관련해서 정리한 글이 있는데 도움이 되면 좋겠습니다. 3번 글이 질문과 가장 잘 맞겠네요.클라우드의 세션 - ① 스티키/클러스터링은 안되요클라우드의 세션 - ② 토큰과 세션클라우드의 세션 - ③ 세션을 토큰으로 대체하기, JWT를 Redis에 넣는다고?

JWT의 개념이 이게 맞나요?

13개의 답변

Q&A 목록