Jwt에 access랑 refresh 있다고 알고있는데
Refresh를 쓰는 용도가 access 재발급이라고 알고있어
Refresh가 있어서 access가 탈취 될때의 피해를 줄이기 위해 access의 유효기간을 짧게 잡는거로 알고있는데
보통 refresh랑 access 랑 둘다
요청 보낼때 쿠기같은거로 함께보내는게 아닌가?
위 가정이 맞다면 어차피 탈취될때 refresh도 같이 탈취되는거 아님?
뭔가 생각해보기로는
인증서버의 서브 도메인으로 refresh 를 저장하고
Access는 루트도메인으로 저장하면
인증서버 찌를때만 리프레시를 보내니까
이렇게하면 리프레시 탈취 가능성을 줄일 수 있지 않을까 생각하는데
실제로 이런 예제를 본적이 없어서
일반적으로는 어떻게 리프레시 탈취를 막는지 궁금함.
지나가는 소리 들어보면 탈취됬으면
블랙리스트 넣으라는데
탈취됬다는건 어떻게 알 수 있는지도 궁금함
Refresh를 쓰는 용도가 access 재발급이라고 알고있어
Refresh가 있어서 access가 탈취 될때의 피해를 줄이기 위해 access의 유효기간을 짧게 잡는거로 알고있는데
보통 refresh랑 access 랑 둘다
요청 보낼때 쿠기같은거로 함께보내는게 아닌가?
위 가정이 맞다면 어차피 탈취될때 refresh도 같이 탈취되는거 아님?
뭔가 생각해보기로는
인증서버의 서브 도메인으로 refresh 를 저장하고
Access는 루트도메인으로 저장하면
인증서버 찌를때만 리프레시를 보내니까
이렇게하면 리프레시 탈취 가능성을 줄일 수 있지 않을까 생각하는데
실제로 이런 예제를 본적이 없어서
일반적으로는 어떻게 리프레시 탈취를 막는지 궁금함.
지나가는 소리 들어보면 탈취됬으면
블랙리스트 넣으라는데
탈취됬다는건 어떻게 알 수 있는지도 궁금함
탈취된 건 탈취된 사람이 좆됐다고 전화 걸어서 알 수 잇음.
이쁜 여자꺼 탈취되면 번호 딸 수있는거임?
나도 완벽히 이해한 건 아니지만, 로컬에 저장된 토큰이 탈취 되는 건 어쩔 수 없고, 네트워크 상에서 나돌아다니는 토큰이 탈취 됐을 때 피해를 최소화 하기 위해 access랑 refresh랑 나눈 거 같음. 대부분의 인증 인가는 access로 이뤄지고, access가 네트워크 상에서 탈취 되더라도 빨리 죽이고 access 발급 받으면 되니까. 그리고 토큰도 생각해보면 password랑 똑같음. db가 털리는 거나 토큰이 털리는 거나 본질적으로는 같은 이야기임.
서버는 클라이언트가 인증된 사용자인지 확인 하기 위해 특정 정보가 필요함. 그게 최초 인가 과정에서는 패스워드인 거고, 이후에는 토큰으로 변경되는 거지. 그래서 식별자가 되는 어떤 값이 왔다 갔다 해야 하는 건 필요불가결함. 탈취 자체를 막기는 힘드니까 이것저것 다 해보다가 access refresh로 나눈 거겟지. 모르긴 몰라도 다 계산 때려보고 만들었을 거임.
물론 db가 털리는 게 훨신 큰 일이긴 함. jwt도 생각해보면 왜 만들었는지 알 것 같긴 함. 패스워드는 보통 다른 곳에서도 공통으로 쓰니까 털릴 거면 jwt 털리는 게 낫지. 패스워드는 최초 로그인 할 때만 날아가고 로그인 하는 당사자 머리 속에 존재할테니.
갑자기 중국ip로 로그인하면 탈취된거임
가끔 로그인할때 이상 ip 로그인 알림 이런게 뜨고 나 아님 누르는게 그런건가
첨에 access랑 refresh 둘 다 발급받고 access가 verify 무사히 되면 refresh는 안감. refresh는 access가 expired일 때만. 그리고 탈취 부분은 이미 xss나 mitm 고려해서 http cookie방식으로 저장 하는 방식을 주로씀. 근데 얘도 사실 공유 pc문제나 이런거를 통해서 털릴 수 있긴 하지. 그리고 어떻게 탈취되지 이거는 지금 시점에서는 굳이 파고드는데 힘 뺄 필요 없고, 그냥 우리가 모르는 zero-day attack으로 탈취 당할 수도 있다. 이렇게 가정하고 이후 전략 수립하는거. 어차피 창과 방패 싸움은 창이 이김
Refresh를 쿠키에 저장하는게 아니야?
저장하지, 근데 cookie는 axios나 fetch에서 설정 해주면 안보낼 수 있음