로그인 후 엑세스 토큰, 리프레시 토큰 둘 다 발급 받아서 클라리언트에 저장 -> 인가 처리는 액세스을 서버에 보내서 처리 -> 액세스 토큰 만료 시 리프레시 토큰을 서버에 보내서 검증 후 액세스 토큰 재발급
이 기본적인 순서로 알고 있는데 이렇게 되면 리프래시 토큰을 서버로 보낼 때 중간 탈취 위험이 있다고 생각이 되어서 내가 생각한 로직은
로그인 후 액세스 토큰은 클라이언트에 저장하고 리프레시 토큰은 Redis에 저장 -> 인가 처리 액세스를 서버에 보내서 처리 -> 액세스 토큰 만료 5분 전 마다 클라이언트에서 서버로 액세스 토큰을 보내고 해당 토큰의 데이터와 일치하는 리프레시 토큰이 Redis에 존재한다면 액세스 토큰 재발급하는 API 요청
이런식으로 구현하는게 리프레시 토큰을 좀 더 안전하게 사용할 수 있는 방안 같은데 허점이 있을까요?
그건 리프레시 토큰을 사용하지 않는 방안 같다만
애초에 리프레시 토큰을 사용하는 이유를 잘 모르는 것 같은데 공부를 좀 더 해봐
클라이언트에서 서버로 요청할 때 리프레시 토큰을 탈취 당할 위험을 없애기 위해서 리프레시 토큰을 DB에만 저장해놓고 액세스 토큰 재발급 받을 때 확인하는 용도로만 사용하는 건 아예 잘못된 생각인가...? 리프레쉬 토큰을 사용하는게 stateless한 특성이 있어서 이를 보완하기 위해서로 알고있는데 리프레시 토큰이 탈취 당하면 진짜 큰일나는거 아닌가..?
...? 탈취당했을때 대응하려고 리프레시 토큰을 쓰는건데
리프레쉬 토큰이 탈취당했었을 때도 바로 대응이 가능한가..? 액세스 토큰이 탈취당했을 때는 리프레쉬 토큰으로 대응 가능하다고만 알고 있어서
아니지 리프레시 토큰은 DB에 접근하니까 바로 대응할 수 있겠네
근데 그렇다고 해도 http 헤더에 아예 리프레시 토큰을 노출 안 하는게 낫지 않나..?
액세스토큰 탈취에는 대응이 불가능하고 재발급이라도 막자고 리프레시토큰 도입하는건데 리프레시 토큰 탈취되면 바로 만료시키면 되지
너는 죽는게 무서우니까 그냥 태어나지 말래? 뭐 말도 안되는 소리를 하냐 자꾸
리프레시 토큰 탈취되면 바로 만료시키면 되는 문제인건 알겠는데 굳이 이걸 클라이언트에 저장을 하는게 잘 이해가 안돼서
클라이언트에는 안 두고 서버에만 두고 관리해도 되지 않아?
재발급할 때는 클라이언트에 가지고 있는 액세스 토큰에 담긴 정보로 DB에 있는 리프레시 토큰이랑 일치하는게 있는지만 확인해도 되잖아
액세스토큰을 보내서 그거랑 일치하는 리프레시 토큰이 있는지 어떻게 알아낼건데.. 액세스토큰은 계속 재발급 가능한데? 동시에 여러개 존재도 가능한데? 키밸류 여러개 유지시키게? 그리고 니 말대로면 액세스토큰 만료되면 재발급은 어떻게 받을래?
만약 액세스토큰 만료되도 재발급용으로 쓸 수 있다면 그게 리프레시 토큰이랑 대체 무슨 차이임?
와 씨바 이해햇다 나 존나 빡대가리인듯
이해했으니 빡대가리까진 아님