JWT 토큰

Рет қаралды 19,770

포프TV

Күн бұрын

JWT 토큰을 사용하면 OAuth 액세스 토큰을 더 잘 관리할 수 있을듯 합니다.

Пікірлер: 28

@user-ug5vu9bd9o 7 жыл бұрын

잘 봤습니다^^ 사용 중인게 나와서 반갑네요. 저도 jwt로 api 엑세스 토큰을 만들어서 쓰고 있습니다. 분당 몇백만 요청이 들어와서 db가 병목될까봐 도입했었죠. admin기능에 valid암호 변경기능 등 몇 가지 만들어서 편의성과 보안도 조금 보완했고요.

@codinglion321 3 жыл бұрын

이 영상을 작년에 봤어야 했는데! 정말 감사합니다!

@포프티비 2 жыл бұрын

지금도 늦지 않았습니다

@user-oq9ri2zr9x 4 ай бұрын

11:32 JWT로 db 에 접근하지 않고 인증처리를 할 수 있는 방법 7년이 지난 지금도 저에게 가르침을 주시는 군요. 감사합니다.

@tteseus 3 жыл бұрын

화이트 리스트이든 블랙리스트이든 갯수와 상관없이 저장소에 접근할때 어쨋든 N번의 Access 를 발생시키니까, 역시 병목현상이 발생할 수 밖에 없지 않을까요? 제생각에는 블랙리스트의 갯수가 훨씬 적을 테니까. 발생하는데로 각 서버의 로컬캐시에 저장시키는 편이 나을 것 같습니다. 화이트 리스트는 너무 많을테니까, 블랙리스트를 로컬 캐시에 저장을 시키는거죠. 물론 리소스 서버가 뜰때와 변경이 될때 블랙리스트를 매번 동기화를 하는 비용이 들겠지만요.

@포프티비 3 жыл бұрын

맞는 말씀입니다. 아니면 그냥 블랙리스트도 크게 신경안쓰고 token의 수명을 좀 짧게(한시간?) 정도로 주는 법도 있겠네요. (사용자들이 그 서비스를 어떻게 쓰느냐 따라 불편하지 않은 정도의 토큰 수명만 주면 뭐가 문제...? 라는 생각 ^^)

@user-ge1yt7vf7q Жыл бұрын

Jwt 설명 G.O.A.T 감사합니다.

@espins6411 7 жыл бұрын

옛날에는 한 사람이 여러 개의 기기를 소유하고 사용하는 경우는 드물었습니다. 그러나 요새는 개인이 집 PC, 회사 PC, 스마트폰, 태블릿 등 다양한 디바이스를 사용하고 다니는 세상입니다. 이런 이유로 자신의 계정을 이용하여 로그인된 디바이스의 목록을 관리할 수 있는 편의 기능을 제공해달라는 고객의 요구사항이 있을 수 있습니다. 더는 필요가 없어진 디바이스를 강제로 로그아웃을 시킨다던가 아니면 디바이스 전체를 로그아웃시키는 기능이 필요할 수 있죠. (이 기능은 구글도 완벽하지 않음) 토큰을 Reset 한다라고도 볼 수 있는데. 이것을 JWT 토큰 기반으로 구현해야 한다면 발급된 토큰을 유효기간과 무관하게 원할 때 아무 떄나 무효화시킬 수 있어야 한다고 보는데요. DB 병목을 완전히 제거하면서 구현하기는 어려울 거 같다는 생각이 듭니다. 으 아이디어 생각하느라 머리가 아프네요.

@espins6411 7 жыл бұрын

또 생각난게... 보안정책에 따라 다르겠지만. 고객이 비밀번호를 바꾸면 비밀번호가 변경되기전에 발급됬던 토큰은 유효기간이 남았더라도 무효화되어야 될텐데요. 이것도 DB 병목 없이는 구현하기 어려울거 같아요. 어떠한 상황이든 토큰의 유효기간을 무조건 보장해주는 것이 제일 쉽네요.

@gwisekor 5 жыл бұрын

저는 rs 알고리즘 방식으로 무효화 시킬때 auth서버 리스타트 시킵니다.

@jin_9707 7 жыл бұрын

감사합니다! 영상 잘 봤습니다!

@user-ek1bh4wd1d 7 жыл бұрын

영상 잘봤읍니다

@digiry 7 жыл бұрын

저도 요즘 auth 구현때문에 고민하고 있었는데 jwt 도 검토해봐야겠네요

@evan-hwang 3 жыл бұрын

양질의 영상 잘 봤습니다!!

@user-bw9ng4wm8h 5 жыл бұрын

JWT를 사용 이유에 대한 정확한 고찰 ㅎㅎ;;

@zbqmaktmxj 7 жыл бұрын

카메라 화질이 너무 좋네요 ㅎ 가까이 올때 얼굴이 완전 디테일하게 다잡히는....

@moisangfroid 7 жыл бұрын

저도 제 웹 프로젝트에 JWT를 썼는데 server side가 stateless한게 참 편하다고 느꼈어요 ㅎㅎ

@young_moneycode9315 Жыл бұрын

악의적인 사용자가 토큰을 무한으로 생성하는 경우 블랙리스트 테이블이 너무 길어져서 서비스에 bottle neck 이 생기는 경우는 어떻게 해야할까요? 몇 천만 row.. 가 되어버린다든지 (글 쓰기, 댓글 쓰기, 좋아요 이런 기능들이 다 결국 request 받아서 블랙리스트 검증을 하고 작동해야할껀데)

@포프티비 Жыл бұрын

JWT 시그내처 검사는 CPU에서 돌립니다. 따라서 사용자가 토큰을 악의적으로 무한으로 생상하더라도 CPU 체크에서 리젝되므로 디비를긁을 이유는 없어보입니다. 만약 그 사용자가 유효한 시그니처를 무한으로 만들고 있다면 그건 시크릿 키가 털린 거니 시크릿 키를 바꿔야합니다.