지금 찾아보고 이해한 건 토큰 만료 기간의 차이인 거 같은데 access 토큰의 경우는 비교적 짧은 시간(30분~ 1시간)만 사용하고 만료되면 다시
발급 받아서 사용하고, refresh 토큰의 경우는 만료 기간이 보통 1주~2주의 정도의 긴 기간이라고 설명을 해주는데
제대로 이해가 안 가서 발급 되는 과정을 찾아봤어요.
찾아보니까 사용자가 로그인 요청을 서버에 하면 두 토큰이 같이 발급이 되는데 access 토큰은 기간이 짧으니까 금방 만료가 되잖아요.
access 토큰이 만료가 되면 클라이언트랑 서버 측이 서로 통신하면서 기존에 만료된 access 토큰을 먼저 확인하고
다시 재발급 받는 과정에서 refresh토큰을 검증하고 올바르다면 access 토큰을 재발급 하는 형태로 이루어지던데 그냥 이중 보안을 위한 관계인가요?
이걸 물어보는 이유가 클라이언트 사이드는 유효성 검사가 빽빽하게 돼있는데 서버 사이드가 비교적 허술해서 어떻게 해야될까 고민중에..
구조적으로 토큰 발급 방식은 토큰 자체로 세션처럼 상태를 유지하면서 만료시킬 수 있는 기능이 없기에 엑세스 토큰의 exp를 짧게 유지하고 리프레시 토큰을 통해서 엑세스토큰이 만료된 경우 재발급 해주는 방법으로
아 무슨 뜻인지 이해했어요
결국엔 세션처럼 사용하는 건 불가능하니까 만료기간의 텀을 두고 refresh 토큰을 통해 재발급 해준다..
약간 이중 보안문 같은 구조네요 제가 이해하던 구조는 맞았군요
걍 엑세스토큰만 발급해라 좆도의미없으니 니가 원하는 stateless로 쓰고싶으면 - dc App
근데 그렇게 엑세스토큰만 사용하면 토큰 탈취에 대한 위협도 있잖아요. 그래서 리프레쉬 토큰도 사용해보려고 하는건데..
ㅋㅋ 리프레쉬토큰은 니가 어찌 확인할래 결국 세션개념 갖고오는건데 - dc App
음.. 결국 리프레쉬 토큰이 서버랑 클라이언트 둘 다에 저장되는 거 아닌가요? 엑세스 토큰이 만료되면 클라이언트에서 제공한 리프레시 토큰이랑, 서버에 저장된 리프레시 토큰이 일치하는지 확인한 후에 엑세스 토큰이 발급되는 걸로 알고 있는데, 로컬 환경에서 구현하면 확인 가능하지 않나요?
검색만 해도 나오는걸 물어보네
세션을 유지함으로써 발생하는 오버헤드와 jwt를 도입해야 하는 상황인지를 고려해야함 그냥 토큰 써보고 싶다고 jwt 쓰는건 별 의미가 없고 요청에 클라이언트 정보가 포함되어야 하는 상황인지를 우선 고려해야
refr token을 도입하는 순간 무상태와는 거리가 멀어짐 refr을 안전하게 저장하기 위해서는 db가 필요할거고 리프레시 토큰을 db까지 가서 확인해야 하는 상황인지, jwt를 쓰는게 세션을 쓰는것 보다 이득이 확실한지를 따져야
결국 서버에서 세션을 저장하는 비용과 부가적인 리프레쉬토큰 관리하는 비용 좆도차이 없으니 그냥 암거나해라 개같은소리말고 - dc App
아무튼 다들 답변 감사합니다. 더 고민하고 찾아봐야겠네요..