Auto RTR은 일반적인 방법은 아닙니다. 왜냐면 RTR을 위한 만료기간 트래킹 및 Refresh API 요청의 책임은 원래 FE에 있기 때문입니다. 그럼에도 불구하고 이렇게 하는 이유는 FE의 개발 편의를 향상시키고 싶기 때문입니다.
이번 구현 방식은 기존 Header 기반 처리 방식과 인증 흐름이 달라서, 익숙하지 않을 수 있다는 점을 고려했습니다.
인증 처리 관련하여 제 구현 목표는, FE 측에서 아무것도 몰라도 인증 처리를 할 수 있게 하여 개발 편의성 및 효율성을 높이는 것입니다.
다만 보안과 같은 우려가 발생할 수는 있겠습니다. 근데 어차피 프론트에서 RTR을 하나 서버에서 RTR을 진행하나 RTK의 호출빈도는 동일하고, RTK 없이는 어떤 잘못된 ATK가 와도 차단시키도록 해서 괜찮습니다.
다만 조금 취약해진 부분은, 원래는 RTR 로직에서 ATK의 유효성까지 검증했었습니다. 하지만 위의 사항을 반영하려면 RTK가 유효하다는 전제하에 ATK 유효성은 검증하지 않도록 해야했습니다. 즉, 검증 로직이 좀 느슨해졌다는 단점이 있고, httpOnly RTK Cookie의 Path도 다소 광범위 적용으로 바꿔야 했어서 CSRF 공격면이 증가했다는 단점 또한 있겠습니다.
또한 Stateless한 처리가 JWT의 설계 철학인데, 이 부분이 다소 모호해졌다는 단점 또한 존재합니다.
저러한 단점들이 있음에도 굳이 그래도 이렇게 진행하는 이유는, 저 또한 이런 방식의 구현은 처음이라 공부도 되고, FE 입장에서는 구현이 편해지니 모두에게 이롭다고 생각했기 때문입니다.
우려되는 보안지점들은 QA때 직접 이런저런 공격을 시도해보고 보강하겠습니다.