프갤에 글쓴 애인데.. 내가 생각하는 JWT 플로우는 이렇게 됨
1. 사용자가 로그인을 요청한다.
2. 서버에서 Access Token과 Refresh Token을 발급한다. Access Token은 쿠키에, Refresh Token은 DB에 저장한다.
3. 사용자가 API 요청을 보내면 Access Token의 복호화 가능 및 만료 여부를 확인한다.
4. Access Token이 만료된 경우 DB에서 Refresh Token을 찾는다.
5. Refresh Token이 유효하면 Access Token을 재발급해주고 요청을 허용한다.
6. Refresh Token이 유효하지 않으면 로그인 페이지로 이동시킨다.
리프레시 토큰은 따로 토큰 발급 없이 저장소에 액세스 토큰: 1 이렇게 저장함
이렇게 되는데 질문
1. refresh token은 클라이언트가 가질 필요가 없다고 생각하는데 전달해서 얻는 이점이 뭐임?
access token이 탈취된다는건 refresh token도 같이 탈취된다는거니까 굳이 줄 필요가 없다고 생각함
그리고 리프레시 토큰이 탈취되면 할 수 있는 대응이 똑같을거같음. 저장소에서 리프레시 토큰 삭제하기말고는 할 수 있는게 없을 것 같은데
2. 리프레시 토큰을 액세스 토큰: 1 이렇게 저장해도 됨?
사용자가 만료된 액세스 토큰을 재발급 받으면 저장소에 있는 액세스 토큰도 갱신되니까, 악성 사용자가 만료된 액세스 토큰을 가지고 요청 보내도 액세스 토큰 새로 발급 불가해서 이런 구조 생각했음
3. jwt 구현하면 스프링 시큐리티의 몇몇 과정들, authentication을 만들고 securitycontext에 저장한다던가 하는 것들 생략해도 됨?
토큰 유효성 확인하고 재발급 혹은 요청 거절하는 필터 하나만 만들어서 등록해주면 될거같은데
"4. Access Token이 만료된 경우 DB에서 Refresh Token을 찾는다." refresh token 찾아서 access token 재발급 하면, DB에 저장된 refresh token의 키값도 새로운 access token으로 업데이트 하겠지? 그러면 타이밍 이슈로 재발급이 완료되기 전에 만료된 access token으로 또 요청이 들어오면 어떻게 될까? 문제가 생기겠지?
그래서 이렇게 처리해야해 "Access Token이 만료된 경우, 403 응답을 준다" "403 응답이 오면, 클라이언트가 미리 받아뒀던 refresh token을 보내서 access token 재발급을 시도한다" "access token 재발급에 성공하면, 기존 요청을 다시 수행한다" "access token 재발급에 실패하면, 재로그인을 위해 로그인 페이지로 리다이렉트 한다"
오 그렇구나.. ㄱㅅㄱㅅ 혹시 다른 부분들은 괜찮음? 리프레시 토큰 구조나 스프링시큐리티 authentication 사용 생략 이거
아 403이 아니라 401 응답이다 추가 질문은 나중에 답해줄게 지금 비쁨
1. refresh token은 클라이언트가 가질 필요가 없다고 생각하는데 전달해서 얻는 이점이 뭐임? - 위의 댓글로도 설명했지만, 이점이 문제가 아니고 무조건 가져야만 함 - refresh token을 안쓰는 슬라이딩 세션이라는 개념도 있긴 한데, 이건 별개의 이야기니까 패스
2. 리프레시 토큰을 액세스 토큰: 1 이렇게 저장해도 됨? - 위의 댓글로도 설명했지만, 당연히 안됨
3. jwt 구현하면 스프링 시큐리티의 몇몇 과정들, authentication을 만들고 securitycontext에 저장한다던가 하는 것들 생략해도 됨? 토큰 유효성 확인하고 재발급 혹은 요청 거절하는 필터 하나만 만들어서 등록해주면 될거같은데 - 생략해도 되긴 되는데, 그럴거면 스프링 시큐리티를 쓸 필요가 아예 없지 - 나중을 생각해서라도 무조건 스프링 시큐리티 쓰는게 이득임
큰 도움 됐습니다 감사합니다 좀 더 공부해야겠네요 흑