쿠키로 구현했을떄는 백에서 다 접근가능해서 내가 어세스토큰 죽으면 자동으로 처리해줬는데
요번에는 프론트에서 api요청시 리퀘스트 헤더에 어세스토큰 넣어서 하는 방식으로 구현하고 있거든?
이럴떄는 프론트에서 어세스토큰 죽으면 알아서 리프래시토큰 서버에 보내고
어세스 토큰 다시 받는 요청을 프론트에서 직접 하는거지?
쿠키로 구현했을떄는 백에서 다 접근가능해서 내가 어세스토큰 죽으면 자동으로 처리해줬는데
요번에는 프론트에서 api요청시 리퀘스트 헤더에 어세스토큰 넣어서 하는 방식으로 구현하고 있거든?
이럴떄는 프론트에서 어세스토큰 죽으면 알아서 리프래시토큰 서버에 보내고
어세스 토큰 다시 받는 요청을 프론트에서 직접 하는거지?
백에서 액세스 토큰 유효성 검사하고 유효기간 끝나서 안되면 프론트에서 리프레시 토큰으로 액세스 토큰 재발급 요청 이렇게 되는거 아닌가? - 2400
액세스 토큰이 만료되면 백엔드에서 프론트로 만료되었다는 응답을 주고 다시 프론트에서 백엔드로 리프레시 토큰 주면서 액세스 토큰 발급 요청 - 2400
ㅇㅇ 첫댓에서 말해준게 맞는데 두번째 댓에서 과정을 처리하는 방식이 이해가 안가서! 요청 후 엑세스 토큰 만료된걸 프론트에서 알아차리고 알아서 다시 백에 다시 리프레시 토큰 보내는 방식이ㅇㅇ 백엔드에서는 구현할때 자세한거는 신경안쓰고 그냥 리프래시 토큰 재발행 api만 만들면 되는거지? 저건 프론트에서 알아서 요청 api 필터 처리하는거고
토큰이 만료 됐는지는 백에서 확인하고 처리해야지프론트는 토큰 만료됐는지 확인할 필요없고백에서 액세스 토큰이 만료 됐다는 응답이 오면다시 리프레시 토큰을 요청에 담아서 보내는 거임그럼 백엔드는 결론적으로1. 요청시 엑세스 토큰이 만료 됐는지 확인하고 처리2. 리프레시 토큰이 유효한지 확인하고 엑세스 토큰 발급두가지가 필요하겠네 - 2400
뭐야 줄바꿈 어디갔노 알아서 잘 보셈 - 2400
나같은 경우, 새로고침 토큰을 프론트로 따로 보내진 않음. 새로고침 토큰은 레디스 같은 메모리 디비에 2주간 저장되고, 만료 시 발급 받은 클라이언트 ID와 클라이언트 시크릿 코드로 토큰이 있는지 확인해서 액세스 토큰 재발급 가능.