spring-boot/spring-security/issue-and-reissue-json-web-token/

[utterances-bot]

JWT(Json Web Token) 발행과 재발행 - Junhyunny’s Devlogs

https://junhyunny.github.io/spring-boot/spring-security/issue-and-reissue-json-web-token/

[kunsanglee]

안녕하세요 작성 하신지 시간이 오래 지나서 질문 남겨도 될지 모르겠습니다. AuthController 에서 reissue 요청이 들어올때 헤더에서 Authorization Bearer 토큰을 받아서 AuthService의 reissue 메서드에 매개변수로 넘겨주는데 이때 Authorization 헤더에서 꺼낸게 refreshToken 인지 궁금합니다. 저는 'Bearer ' 이게 붙어서 accessToken을 받아오는구나 생각했는데 AuthService에서 reissue메서드를 진행할때 resolveToken(bearerToken) 의 결과로 refreshToken이 반환되는 걸 보고 제가 잘못 이해한 것 같아 질문드립니다.. 그리고 요청헤더에 Authorization -> accessToken, Cookie -> refreshToken 이런식으로 담는걸로 알고있는데 로그인과 재발급 이후 반환되는 토큰을 어떻게 처리 하시는지도 궁금합니다. 멋대로 와서 질문만 쏟아놓고 가서 죄송합니다ㅜ

[Junhyunny]

일단 첫 질문에 답변드리면 /reissue 경로에서 받는 토큰은 리프레시(refresh) 토큰이 맞습니다. 코드를 자세히 살펴보시면 해당 경로를 통해 전달받은 토큰에서 클레임 정보를 추출할 때 사용하는 시크릿(secret)은 리프레시 토큰을 위한 별도 시크릿입니다. 액세스(access) 토큰을 전달하는 경우 에러가 발생합니다.

두번째 질문에 대한 답변은 프로젝트 상황과 개발자가 구현하기에 따라 다른 것 같습니다. XSS 공격을 막고자 토큰을 쿠키에 담는 것은 좋은 아이디어 같습니다. 쿠키에 담긴 정보는 공격자가 직접 핸들링하기 까다롭지만, 어쨋든 쿠키에 담긴 리프레시 토큰 정보를 추출하는 로직과 CSRF 공격을 방어하기 위한 코드는 별도로 추가될 필요가 있습니다.

이 글을 쓰는 당시에 액세스 토큰과 리프레시 토큰을 모두 브라우저 로컬 스토리지(local storage)에 저장했고 액세스 토큰이 만료된 경우 axios 인터셉터에서 리프레시 토큰을 사용해 액세스 토큰을 재발급 받는 로직을 가장 쉽게 구현하는 방법이 다시 헤더에 담아 재시도(retry)하는 방법이어서 이렇게 구현했던 것으로 기억합니다. 보안적으로 더 안정적인 방법을 사용하시는게 더 좋을 것 같다는 의견드립니다.

[kunsanglee]

질문 수준이 낮은데도 친절하게 답변해주셔서 정말 감사드립니다! 말씀해주신 CSRF 공격에 대해 준현님이 작성하신 포스트도 참고하려고 합니다. 질 좋은 포스트를 많이 올려주셔서 엄청 공부가 되네요. 정말 감사합니다!!