[프로젝트]🔒 RefreshToken 구현 고민해보기

리프레시 토큰이 필요한 이유

방끗 프로젝트에서는 JWT 토큰을 사용해 인증/인가 서비스를 구현했다. 이때 토큰의 유효시간은 2시간이다. 방을 둘러보며 체크리스트를 작성하는데 2시간이면 충분하다고 판단했기 때문이다. 그런데 서비스를 이용해보니 2시간이 충분하지 않을 수도 있겠다는 생각이 들었다. 오후에 잠시 체크리스트 질문 목록을 확인하고 몇 시간이 지난 뒤 방을 둘러보는 사용자가 있을 수도 있다. 또한 방을 둘러본 뒤 계약을 하기 위해 체크리스트 질문 목록을 다시 확인하며 고민하는 사용자도 있을 것이다. 서비스를 이용하는 도중 로그인이 풀린다면 굉장히 불편하다.

로그인 시간을 더 길게 가져가기 위해 방끗팀은 액세스 토큰, 리프레시 토큰을 도입하기로 결정했다. 토큰의 유효시간을 더 늘리는 방법도 있을 것이다. 하지만 보안상의 이유로 선택하지 않았다. 토큰을 탈취당할 경우 서버에서 해줄 수 있는 것이 없기 때문이다. 유효시간이 만료되는 동안 해커는 계속해서 서비스에 접근할 수 있다는 문제점이 있었다.

리프레시 토큰을 구현하는 일반적인 방법

기존에 알고 있던 리프레시 토큰 구현 흐름은 다음과 같다.

• 로그인시 액세스 토큰, 리프레시 토큰을 함께 반환한다.
• 액세스 토큰은 유효 시간을 짧게, 리프레시 토큰은 상대적으로 길게 설정한다.
  • 보통 액세스 토큰은 15 ~ 30분, 리프레시 토큰은 1 ~ 2주 사이로 설정한다.
• 클라이언트 → 서버로 API 요청시 액세스 토큰을 사용한다.
• 액세스 토큰이 만료되면 리프레시 토큰으로 새롭게 액세스 토큰을 갱신한다.

리프레시 토큰 구현하기

✅ 리프레시 토큰을 서버에 저장해야 할까?

보통은 레디스를 활용해 리프레시 토큰을 서버에 저장하는 구현방식을 많이 보았다. 리프레시 토큰이 탈취되었는지 확인할 수 있고, 탈취된 경우 유효 시간을 만료시킴으로써 추가적인 문제를 방지할 수 있기 때문이다.

다음의 시나리오로 리프레시 토큰이 탈취되었는지 알 수 있다.

• 서버에서 (key, value) 쌍으로 액세스 토큰과 리프레시 토큰을 저장한다.
• 해커가 리프레시 토큰을 탈취해 액세스 토큰을 발급하는 요청을 보낸다.
• 서버는 새롭게 액세스 토큰을 갱신하고 key 값을 갱신한다.
• 정상적인 사용자가 리프레시 토큰으로 새로운 액세스 토큰을 요청한다.

그런데, 사용자의 액세스 토큰과 일치하는 key값이 존재하지 않는다. 이미 해커가 액세스 토큰을 갱신했기 때문이다. 해당 문제가 발견되면 그 즉시 해당 액세스 토큰을 만료시켜 해커의 접근을 막을 수 있다.

하지만 리프레시 토큰을 데이터베이스에 저장하는 순간 JWT 토큰이 제공하는 stateless 장점이 사라진다고 생각했다. state한 상태에서는 서버 간의 값을 일치시키는 작업이 필요하고, 매 요청마다 정상적인 사용자인지 확인하기 위해 데이터베이스에서 값을 조회하는 과정에서 서버의 부담이 증가하게 된다. stateless한 장점을 취하고자 JWT 토큰을 사용했는데 리프레시 토큰을 사용하면서 그 장점을 잃고 싶지는 않았다. 기존에 토큰을 쿠키에 저장했던 것처럼 리프레시 토큰도 쿠키에 같이 저장하면 문제가 되나?를 고민하게 되었다.

✅ 보안 이슈는 무엇이 있는가?

그렇다면 웹 통신과정에서 일어날 수 있는 보안 이슈를 알아봐야 했다. XSS(Cross-Site Scripting)와 CSRF(Cross-Site Request Forgery)이 가장 흔하게 발생하는 공격 유형이면서 가장 자주 등장하는 개념이다.

XSS 공격

공격자가 웹 페이지에 악의적인 스크립트를 삽입하여 사용자의 정보를 탈취하거나 조작하는 공격이다. 예를 들어, 공격자가 게시판에 악의적인 스크립트를 포함한 글을 작성하면, 이 글을 읽는 사용자의 브라우저에서 해당 스크립트가 실행되어 공격자에게 정보가 유출될 수 있다. 토큰이 스크립트로 접근할 수 있는 곳에 저장되어 있다면 XSS 공격에 취약해진다.

CSRF 공격

사용자가 자신의 의지와 무관하게 공격자가 의도한 행위를 웹 애플리케이션에 요청하게 만드는 공격이다. 예를 들어, 사용자가 인터넷 뱅킹 서비스에 로그인한 상태에서 공격자가 준비한 결제 요청 링크를 클릭하게 되면, 사용자는 자신의 의지와는 무관하게 결제를 진행하게 된다. 이를 방지하기 위한 방법으로는 CSRF 토큰 사용, 쿠키의 SameSite 속성 설정, Referrer 검증 등이 있다.

✅ 쿠키를 사용하면 해당 보안 이슈를 해결할 수 있는가?

Cookie + HttpOnly + secure + Same Site 옵션을 모두 활용한다면 위에서 말한 보안 이슈를 예방할 수 있다. HttpOnly 옵션을 사용하면 스크립트를 통해 쿠키값을 읽어볼 수 없기 때문에 XSS 공격에 대해 방어할 수 있다. 또한 SameSite 옵션을 사용하면 쿠키를 전송할 범위를 설정할 수 있다. 특정 요청을 제외하고는 현재 페이지의 도메인과 요청받는 도메인이 같아야만 쿠키를 전송해준다. 해커가 다른 사이트를 통해 요청을 보내도 도메인이 일치하지 않아 CSRF 공격에 대해 방어할 수 있다.

✅ 정리

리프레시 토큰이 탈취당하면 계속해서 액세스 토큰을 발급받을 수 있기 때문에 보안 문제에 대해 깊게 고민해봐야 한다. 그리고 구현 방식을 한 번 정하면 바꾸기 쉽지 않기 때문에 정말 많은 고민을 했다.

하지만 아무리 생각해봐도 보안 문제를 고민한다면 리프레시 토큰을 안전하게 사용하기 위해 끝도 없이 이 방법, 저 방법을 갖다 붙여야 했다. 예를 들어 리프레시 토큰을 한 번만 사용할 수 있도록 하는 RTR(Refresh Token Rotation) 개념이라던지 .. 점점 JWT 토큰에 대한 회의감이 든 것도 사실이다. 편리성과 보안성을 모두 챙기기는 쉽지 않았다.

그래서 오랜 고민 끝에 다음의 방식을 선택했다.

• 서버에서는 액세스 토큰과 리프레시 토큰을 쿠키로 담아 전달한다.
• 액세스 토큰이 만료되면 API 요청을 보내 액세스 토큰을 갱신해 쿠키를 갱신한다.

쿠키 옵션을 제대로 설정해준다면 어느 정도 보안 이슈를 막을 수 있다고 생각했다. 보안에 대한 조치가 미흡한 점이 조금 걸리지만 지금 단계에서 당장 필요성을 느끼지 못하는 작업은 진행하지 않기로 했다.

프론트와 협업하기

✅ 예외 메시지 정리

프론트에서 액세스 토큰이 만료되었음을 알고 /reissue API 요청을 보내기 위해서는, 즉 프론트 코드 내에서 분기처리하기 위해서는 예외 메시지를 같이 맞춰봐야 했다. 토큰을 사용했을 때 발생할 수 있는 시나리오를 쭉 나열해보고 예외 메시지를 정리했다.

요청 유형	리프레시 토큰	액세스 토큰	처리 결과	다음 요청
일반 요청	O	X	"토큰 정보가 존재하지 않습니다. 토큰을 재발급해주세요."	/accessToken/reissue
일반 요청	X	O	"로그인이 필요한 사용자입니다."	/oauth/login
일반 요청	X	X	"로그인이 필요한 사용자입니다."	/oauth/login
/accessToken/reissue	X	X	"토큰 정보가 존재하지 않습니다. 토큰을 재발급해주세요."	/oauth/login
/accessToken/reissue	X	O	"로그인이 필요한 사용자입니다."	/oauth/login

이 과정에서 예외 메시지를 던질 때 예외 코드가 필요하다는 것을 느꼈다. 예외 메시지로 프론트와 소통하는 것이 쉽지 않았고 예외 상황을 문자열로 판단하는 것은 바람직해보이지 않았다. 또한 백엔드 코드 로직내에서 액세스 토큰과 리프래시 토큰이 공통으로 처리하는 부분이 있어 현재는 예외 메시지가 비슷한데 이 부분도 각 상황에 따라 더 적절한 예외 메시지로 리팩토링할 예정이다.

✅ reissue API가 정말 필요한가?

서버에서 구현한 reissue API를 프론트와 협업하면서 고민이 생겼다. 예외 메시지를 맞추는 작업이 생각보다 쉽지 않았고, "차라리 예외 메시지를 전달하지 않고, 액세스 토큰이 만료되면 서버가 알아서 쿠키를 설정해주는 방식이 더 나은 게 아닐까?"라는 이야기가 나왔다. 하지만 이 방식에 대해 왠지 모를 찝찝함이 있었다. 여러 가지를 충분히 고려하지 못한 상태에서 결정을 내리기에는 경험과 근거가 부족하다고 느꼈다. 결국 시간 부족으로 인해 일단은 구현된 Reissue API를 사용하는 쪽으로 결론을 내렸지만, 이 방식에 대해서도 추가적인 논의가 필요할 것 같다.

데모데이 피드백

데모데이에 2가지 피드백을 받을 수 있었다. 이에 대한 답은 다시 천천히 고민해보자 😃

• 지금의 방식대로라면 액세스 토큰만 있어도 되는 것 아닌가요?
• 정말 보안 문제를 모두 고려해보았나요?