일반적인 상황에서 JWT는 세션에 비해 상대적으로 보안에 취약하기 때문에 로드밸런싱이 들어갈 정도로 큰 서비스들은 웬만하면 세션 방식으로 개발합니다. 물론 개인 프로젝트에서 REST API 쓸 땐 개꿀딱입니다.

@@진_비 네 맞습니다. 보안에 세션보다 취약하다는 단점이 있죠 세션은 탈취당하면 서버에 세션정보가 남아있기에 강제 로그아웃이나 제어하는 방법이 있습니다만 토큰 발급은 이미 토큰을 발급한뒤고 서버에 아무것도 없기에 제어할 방법이 없어요 기업들에서는 병행해서 많이 쓰는것으로 알고 있습니다. jwt 보안 단점을 보완하기위하여 유투버님께서 알려주신 jwt access token외에 expire 기간이 긴 refresh token을 같이 발급(두개) 하거나 블랙리스트 db를 하나 만들어 탈취당했을때에 위험을 방지하기도 하는데 이러면 statusful 방식으로 세션하고 비슷해져버려서 의미가 사라진다는 단점이 있지만 정보를 덜 저장한다는 의미에서는 쓰이고 있죠 세션에서도 여러 서버로 로드밸런싱 하는경우 세션정보를 잃지 않기 위해 아래와 방법을 쓰고 있습니다. 1. 고정 세션 2. 세션클러스터링 2-1) 세션복제 2-2) 세션 스토리지 결국은 상황에 맞춰쓰는데.. MSA 구축을 추구하는 기업에서는 JWT를 늘려가려는 추세인듯 싶습니다.

와 역시 구글링해서 형식적인 개념을 읽는 것보다 현직자분의 말 한마디가 확실히 도움이 되네요... 그동안 개인적으로 의문이 좀 많았던 개념이었는데 덕분에 많이 알아갑니다!!!

JWT가 서버가 클 수록 오히려 장점을 갖는걸로 알고있는데 아닌가요? 세션은 접속자가 많을 수록 세션DB의 부담이 늘어나기 때문에요. JWT는 파싱하고 검증만 하면 되서 부하도 줄고 속도도 더 빠르다고 알고 있습니다

응원 감사합니다😊

항상 시청해주셔서 감사합니다!

더 열심히 하겠습니다~!!

제 생각에는 세션같은경우, 세션DB를 통해 해당 유저를 Find하여 강제 세션아웃 시킬수 있기때문에 원격이 된다고 하신것 같습니다. JWT의 경우에는 DB나 서버의 자원에서 갖고있는 부분이 아니기때문에, 일반적으로 Decode하여 유저인지 인증하는 용도로 쓰입니다. JWT를 Expire(만료) 시키기 위해서는 Client에서 요청을 보내야만 JWT를 만료 할 수 있습니다. 순수하게 JWT 자체로 계정이 3명이니, 원격 로그아웃을 해주세요. 라는 가정을 하신다면, JWT를 발급받은 ID들이 DB혹은 서버의 메모리에 저장되어야 합니다. 그렇게 될 경우 JWT의 장점인 서버 자원을 사용하지 않는다에 위배됩니다. 해당 방식은 세션과 동일해 지는 부분이구요. JWT자체에 관한 정보를 Server에선 갖고 있지 않으므로, 요청이 오기전까지 Expire할 수 없습니다. 만약 원격 Expire를 하신다면, 요청이 올때까지 기다렸다가 해당 JWT를 Decode한 이후, UserID를 확인하여 Expire하는 Logic을 구현하시면 될 것 같습니다. 흔치 않는 경우이기때문에 해당 설명에서는 원격 로그아웃이 불가능하다 라고 하시는것 같습니다.

@@meonton9406 이해했어요 감사합니다!

@@meonton9406 세상 능력자

세션 같은 경우 A = User1 이런 식으로 매칭해서 서버에 저장하고 있기 때문에 세션 값으로 A를 보내주면 User1 이라고 인식하는 방식입니다. 그래서 서버가 다르면 인식하지 못 하는 거고요. 로그아웃은 목록에서 A라는 값만 지우면 됩니다. JWT 같은 경우는 값 자체를 복호화해서 정보를 알아내는 방식입니다. 예를 들어 JWT가 User1_AA_Gildong_AA_11/1 라고 했을 때 이 값 자체를 복호화 해서 User1, Gildong, 11/1 이라는 정보를 얻어 유저를 구분하는 방식입니다. 토큰 안에는 만료일 정보도 같이 들어있는데 이 만료일이 지나면 토큰은 사용할 수 없습니다. 로그아웃이라는 개념 자체가 없고 토큰 만료일을 30분, 2시간 등으로 짧게 설정하고 자주 자주 발급하는 방식으로 사용하거나 로그아웃 요청이 들어오면 블랙리스트를 만들어서 관리하는 식으로 사용합니다. +) 윗 분 말씀에 첨언하자면 JWT는 서버에서 임의로 만료시킬 수 없습니다.

db는 말그대로 그냥 아무거나 데이터를 저장하는 장소입니다. 세션 db라고 한다면 세션값만 저장하는거겟죠. 여기서 db를 따로 나눈다고 한다면, 그 이유는 db 하나에 모든 정보가 들어가면 db에 정보를 읽고 쓸때 부하가 너무많이들어가니까 나눠놓은것일뿐입니다. 그래서 딱히 나누고 안나누고는 개발자 자유이고 기기성능이나 서버사용량 등에 따라 다른겁니다. 다만 세션의경우 모든 요청에 모조리 포함되니까 그만큼 db를 읽는양이 압도적이라서 db를 따로 빼놓는 경우가 대부분일뿐 꼭 나눠야하는건아니에요

@@ttiyongti5945 아하! 너무 이해가 잘되네요~ 저는 세션DB라는 것이 따로 존재하나 싶었는데 그냥 지칭하는 말이었군요. 감사합니다:)

관심가져주셔서 감사합니다~!