JWT 전달 방식에 대한 고찰 (Header VS Cookie)

JWT에 대해

• access token만을 사용한다면 탈취됐을 때, access token이 만료될 때 까지 탈취자는 계속 사용자의 정보를 사용할 수 있다.
• 그래서 access token의 만료 기한을 짧게 설정하는데, 이렇게 하면 사용자가 자주 로그인을 해야하는 경험적 불편함이 생긴다.
• 그래서 access token이 만료됐을 때 재발급하여 문제를 해결하는 것이 refresh token이다.

RTR(Refresh Token Rotation)

• access token도 탈취되는데 refresh token이라고 탈취가 안당하겠나? → 일반적으로 HttpOnly 쿠키로 저장되어 XSS에 안전하지만, 가능성이 아예 없는 것은 아니다.
• 그래서 나온게 RTR
• access token을 재발급 해줄 때 refresh token도 새 refresh token으로 발급하는 방식

토큰 발급시 header-body vs cookie

• refresh token은 cookie에 담아서 보안옵션을 설정한 뒤 전달한다.
• access token은 header-body(memory) 또는 cookie에 담아서 전달할 수 있다.
• header-body(memory) : CORS 이슈를 더 세밀하게 컨트롤 가능하고 쿠키 스토리지와 독립적이라 프론트엔드에서 관리하기 편하다. 또한 모바일 앱처럼 쿠키를 관리하기 힘들 때 사용에 용이하다. 단, 로컬스토리지에 저장하면 XSS 공격에 취약할 수 있다.
• Cookie : HttpOnly, Secure, SameSite 옵션을 설정하면 XSS·CSRF 방어에 유리하고, 매 요청마다 자동으로 cookie가 전달되기 때문에 프론트엔드 코드가 간결해진다. 단, CORS 관리가 까다롭고 모바일 앱에서 사용하기 불편하다.

결론

• 상황, 환경에 따라 다르게 선택할 수 있다.
• 웹 기반 서비스: 쿠키
• spa: access토큰은 header-body(메모리)
• 모바일 앱: access 토큰은 header-body(메모리), refresh 토큰은 header-body(secure storage)