리프레시를 세션레코드로 분리보관하고 쿠키에넣고 엑세스는 스티트리스하게 검증만 처리하는 구조 알아봐봐
결국 세션처리를 하는데 있어서 둘다 클라이언트 스토리지에 쑤셔박는 기초적인 스테이트리스면 개박살나는건 당연한거임 - dc App
익명(223.38)2025-12-11 01:19
누가 너 스마트폰을 훔쳐갔다고 상상해봐
익명(114.30)2025-12-11 04:49
답글
스마트폰 도난은 사용자 책임이지 - dc App
고개를전라전라(needle4620)2025-12-11 10:46
리프레시 안써도됨
토큰마다 expire 시간 잘해두고 그 기간동안 엑세스토큰 블락처리하면됨.
근데 대부분 엑세스토큰이 털리는거면 사용자 브라우저 쿠키가 어디서 줄줄 세고있는거라
토큰받아도 똑같은 상황이 일어나기에
그냥 난 디비에 jwt_id 라고 따로 별도관리해둠, 사용자 계정 정지시키고 메일이나 뭐 통보해서 비번알아서 바꾸고 해라 하고 바꾸면 jwt_id 카운팅되는식으로
익명(182.231)2025-12-11 07:46
답글
엑세스토큰 안에 jwt_id 값 비교해서 허가시켜줌,
그냥 웹만 하는거면 세션쓰는게 편함. 토큰은 연계해야하는 내부 , 외부로 서비스가 존나게 많으면 용이함
익명(182.231)2025-12-11 07:50
답글
@ㅇㅇ(182.231)
덤으로 비번 바꿧는데 또 이런상황이되면 그냥 사용자 문제라고 쐐기박아야함, 어쩔수가없음
리프레시를 세션레코드로 분리보관하고 쿠키에넣고 엑세스는 스티트리스하게 검증만 처리하는 구조 알아봐봐 결국 세션처리를 하는데 있어서 둘다 클라이언트 스토리지에 쑤셔박는 기초적인 스테이트리스면 개박살나는건 당연한거임 - dc App
누가 너 스마트폰을 훔쳐갔다고 상상해봐
스마트폰 도난은 사용자 책임이지 - dc App
리프레시 안써도됨 토큰마다 expire 시간 잘해두고 그 기간동안 엑세스토큰 블락처리하면됨. 근데 대부분 엑세스토큰이 털리는거면 사용자 브라우저 쿠키가 어디서 줄줄 세고있는거라 토큰받아도 똑같은 상황이 일어나기에 그냥 난 디비에 jwt_id 라고 따로 별도관리해둠, 사용자 계정 정지시키고 메일이나 뭐 통보해서 비번알아서 바꾸고 해라 하고 바꾸면 jwt_id 카운팅되는식으로
엑세스토큰 안에 jwt_id 값 비교해서 허가시켜줌, 그냥 웹만 하는거면 세션쓰는게 편함. 토큰은 연계해야하는 내부 , 외부로 서비스가 존나게 많으면 용이함
@ㅇㅇ(182.231) 덤으로 비번 바꿧는데 또 이런상황이되면 그냥 사용자 문제라고 쐐기박아야함, 어쩔수가없음
여러 기기로 접속 테스트해본적없냐
털리는 경로와 확률이 다름
똑같은곳에 똑같이 넣어놓으면 크게 의미 없음
그게 어케 다름?
쿠키에 넣느냐 로컬스토리지에 넣느냐 헤더에 보내느냐 바디에 보내느냐 xss공격에 털리는지 세션하이재킹에 털리는지가 달라짐
그래서 액세스토큰은 시간 일부러 짧게두잖아. 그 기간동안은 털리면 소용 없는 거 맞음..
그냥 외워
엑세스가 아니라 엑섹스