화이트 리스트이든 블랙리스트이든 갯수와 상관없이 저장소에 접근할때 어쨋든 N번의 Access 를 발생시키니까, 역시 병목현상이 발생할 수 밖에 없지 않을까요? 제생각에는 블랙리스트의 갯수가 훨씬 적을 테니까. 발생하는데로 각 서버의 로컬캐시에 저장시키는 편이 나을 것 같습니다. 화이트 리스트는 너무 많을테니까, 블랙리스트를 로컬 캐시에 저장을 시키는거죠. 물론 리소스 서버가 뜰때와 변경이 될때 블랙리스트를 매번 동기화를 하는 비용이 들겠지만요.
옛날에는 한 사람이 여러 개의 기기를 소유하고 사용하는 경우는 드물었습니다. 그러나 요새는 개인이 집 PC, 회사 PC, 스마트폰, 태블릿 등 다양한 디바이스를 사용하고 다니는 세상입니다. 이런 이유로 자신의 계정을 이용하여 로그인된 디바이스의 목록을 관리할 수 있는 편의 기능을 제공해달라는 고객의 요구사항이 있을 수 있습니다. 더는 필요가 없어진 디바이스를 강제로 로그아웃을 시킨다던가 아니면 디바이스 전체를 로그아웃시키는 기능이 필요할 수 있죠. (이 기능은 구글도 완벽하지 않음) 토큰을 Reset 한다라고도 볼 수 있는데. 이것을 JWT 토큰 기반으로 구현해야 한다면 발급된 토큰을 유효기간과 무관하게 원할 때 아무 떄나 무효화시킬 수 있어야 한다고 보는데요. DB 병목을 완전히 제거하면서 구현하기는 어려울 거 같다는 생각이 듭니다. 으 아이디어 생각하느라 머리가 아프네요.
또 생각난게... 보안정책에 따라 다르겠지만. 고객이 비밀번호를 바꾸면 비밀번호가 변경되기전에 발급됬던 토큰은 유효기간이 남았더라도 무효화되어야 될텐데요. 이것도 DB 병목 없이는 구현하기 어려울거 같아요. 어떠한 상황이든 토큰의 유효기간을 무조건 보장해주는 것이 제일 쉽네요.
악의적인 사용자가 토큰을 무한으로 생성하는 경우 블랙리스트 테이블이 너무 길어져서 서비스에 bottle neck 이 생기는 경우는 어떻게 해야할까요? 몇 천만 row.. 가 되어버린다든지 (글 쓰기, 댓글 쓰기, 좋아요 이런 기능들이 다 결국 request 받아서 블랙리스트 검증을 하고 작동해야할껀데)
JWT 시그내처 검사는 CPU에서 돌립니다. 따라서 사용자가 토큰을 악의적으로 무한으로 생상하더라도 CPU 체크에서 리젝되므로 디비를긁을 이유는 없어보입니다. 만약 그 사용자가 유효한 시그니처를 무한으로 만들고 있다면 그건 시크릿 키가 털린 거니 시크릿 키를 바꿔야합니다.
![[보안] HTTPS를 싸게](http://i.ytimg.com/vi/nf6NnD7V8Eg/mqdefault.jpg)
잘 봤습니다^^
사용 중인게 나와서 반갑네요.
저도 jwt로 api 엑세스 토큰을 만들어서 쓰고 있습니다. 분당 몇백만 요청이 들어와서 db가 병목될까봐 도입했었죠.
admin기능에 valid암호 변경기능 등 몇 가지 만들어서 편의성과 보안도 조금 보완했고요.
이 영상을 작년에 봤어야 했는데! 정말 감사합니다!
지금도 늦지 않았습니다
화이트 리스트이든 블랙리스트이든 갯수와 상관없이 저장소에 접근할때 어쨋든 N번의 Access 를 발생시키니까, 역시 병목현상이 발생할 수 밖에 없지 않을까요? 제생각에는 블랙리스트의 갯수가 훨씬 적을 테니까. 발생하는데로 각 서버의 로컬캐시에 저장시키는 편이 나을 것 같습니다. 화이트 리스트는 너무 많을테니까, 블랙리스트를 로컬 캐시에 저장을 시키는거죠. 물론 리소스 서버가 뜰때와 변경이 될때 블랙리스트를 매번 동기화를 하는 비용이 들겠지만요.
맞는 말씀입니다. 아니면 그냥 블랙리스트도 크게 신경안쓰고 token의 수명을 좀 짧게(한시간?) 정도로 주는 법도 있겠네요. (사용자들이 그 서비스를 어떻게 쓰느냐 따라 불편하지 않은 정도의 토큰 수명만 주면 뭐가 문제...? 라는 생각 ^^)
11:32 JWT로 db 에 접근하지 않고 인증처리를 할 수 있는 방법
7년이 지난 지금도 저에게 가르침을 주시는 군요. 감사합니다.
옛날에는 한 사람이 여러 개의 기기를 소유하고 사용하는 경우는 드물었습니다. 그러나 요새는 개인이 집 PC, 회사 PC, 스마트폰, 태블릿 등 다양한 디바이스를 사용하고 다니는 세상입니다. 이런 이유로 자신의 계정을 이용하여 로그인된 디바이스의 목록을 관리할 수 있는 편의 기능을 제공해달라는 고객의 요구사항이 있을 수 있습니다. 더는 필요가 없어진 디바이스를 강제로 로그아웃을 시킨다던가 아니면 디바이스 전체를 로그아웃시키는 기능이 필요할 수 있죠. (이 기능은 구글도 완벽하지 않음) 토큰을 Reset 한다라고도 볼 수 있는데. 이것을 JWT 토큰 기반으로 구현해야 한다면 발급된 토큰을 유효기간과 무관하게 원할 때 아무 떄나 무효화시킬 수 있어야 한다고 보는데요. DB 병목을 완전히 제거하면서 구현하기는 어려울 거 같다는 생각이 듭니다. 으 아이디어 생각하느라 머리가 아프네요.
또 생각난게... 보안정책에 따라 다르겠지만. 고객이 비밀번호를 바꾸면 비밀번호가 변경되기전에 발급됬던 토큰은 유효기간이 남았더라도 무효화되어야 될텐데요. 이것도 DB 병목 없이는 구현하기 어려울거 같아요. 어떠한 상황이든 토큰의 유효기간을 무조건 보장해주는 것이 제일 쉽네요.
저는 rs 알고리즘 방식으로 무효화 시킬때 auth서버 리스타트 시킵니다.
감사합니다! 영상 잘 봤습니다!
영상 잘봤읍니다
Jwt 설명 G.O.A.T 감사합니다.
저도 요즘 auth 구현때문에 고민하고 있었는데 jwt 도 검토해봐야겠네요
양질의 영상 잘 봤습니다!!
JWT를 사용 이유에 대한 정확한 고찰 ㅎㅎ;;
악의적인 사용자가 토큰을 무한으로 생성하는 경우 블랙리스트 테이블이 너무 길어져서 서비스에 bottle neck 이 생기는 경우는 어떻게 해야할까요? 몇 천만 row.. 가 되어버린다든지 (글 쓰기, 댓글 쓰기, 좋아요 이런 기능들이 다 결국 request 받아서 블랙리스트 검증을 하고 작동해야할껀데)
JWT 시그내처 검사는 CPU에서 돌립니다. 따라서 사용자가 토큰을 악의적으로 무한으로 생상하더라도 CPU 체크에서 리젝되므로 디비를긁을 이유는 없어보입니다.
만약 그 사용자가 유효한 시그니처를 무한으로 만들고 있다면 그건 시크릿 키가 털린 거니 시크릿 키를 바꿔야합니다.
카메라 화질이 너무 좋네요 ㅎ 가까이 올때 얼굴이 완전 디테일하게 다잡히는....
안녕하세요. JWT를 사용하려면 key값을 서버와 사용자가 둘다 알고있어야하는데, 그렇다면 key는 사용자별로 서버에서 따로 db에 들고있어야 하는 건가요?
사용자는 토큰만 가지고 있으면 되고 키는 알필요 없어요
저도 제 웹 프로젝트에 JWT를 썼는데 server side가 stateless한게 참 편하다고 느꼈어요 ㅎㅎ
헤더 노출 되면 끝 아닌가요?
+Ricky Yu 그건 token기반 api호출은 다 마찬가지죠
답변 감사합니다 ^^
헤더가 노출되도 rs방식으로 되어 있으면 복호화 하기 어렵지 않나요?
Jwt는 인코딩만 되어있어 애초에 안에있는 모든 데이터를 다 볼 수 있습니다
3등
조회수가 벌써 3회!