Refresh Token DB 보관 방식으로 보안성 높이기

[summersummerwhy]

🔖 연관된 이슈

• closes Refresh Token 보완 #318

📂 작업 내용

• 현재는 access Token, refresh Token이 같은 키로 생성되며, jwtService만이 verify하여 검증하는 구조를 가지고 있어 refesh token의 의미가 딱히 없는 상태 입니다
• refresh Token을 DB에 저장해야하는 이유는 다음과 같습니다
  • 1. jwt secret key를 얻는 다면 access, refresh Token을 둘 다 위조해낼 수 있는 상황입니다. access Token은 1시간 정도의 유효기간을 가지고 있어 보안에 크게 위협이 되지 않는 상황이지만, 유효기간이 긴 refresh Token과 같은 경우에는 문제가 됩니다. 따라서 사용자의 유효한 refresh Token을 사용자 별로 하나로 특정해 놓는 것이 보안상 좋습니다.
  • 2. jwt는 Stateless 원칙으로, 인증 후 토큰 폐기가 어렵기 때문에 로그아웃 등 기타 정책에 의해 Token을 DB에서 폐기함으로써 특정 토큰을 관리할 수 있습니다.

따라서 다음과 같은 구현을 진행했습니다.

1. user 엔티티에 refresh Token column 추가 (nullable, string type)
2. 사용자가 로그인 후 refresh Token, access Token을 쿠키에 보관하면서 refresh Token은 따로 DB에도 저장.
3. refresh Token 생성 방법도 보안성을 높임. 토큰 아이디를 uuid로 payload로 추가.
4. access Token이 만료되어 다시 발급받기 위해 refresh Token을 검증받을 때, refresh Token을 verify 한 후 DB에 보관된 refresh Token과 일치하는지도 비교하게 함. 다른 경우 invalid token error가 생성됨.
5. 사용자가 로그아웃 할 시 쿠키가 비워지면서 db에 있는 해당 사용자의 refresh Token도 null로 reset 됨

📑 참고 자료 & 스크린샷 (선택)

📢 리뷰 요구사항 (선택)

• db에 보관된 refresh token과 같은 경우 모두 tokenService가 관리합니다. refresh Token을 생성해서 업데이트, 로그아웃이 진행되어 null로 비우기, 토큰 검증과정에서 비교하기 등의 작업을 모두 tokenService에서 작업하도록 구현하였습니다.
• 사용자당 하나의 refresh token만이 유효하기 때문에 다른 브라우저로 로그인 시, 원래 로그인 되어있던 브라우저는 로그아웃 처리될 것입니다. 이에 대해 어떻게 생각하시나요? 일단은 크게 불편한 사항은 아니라고 생각해서 user entity에 하나만 보관되게 만들었습니다. (아닐 경우 refresh token 전용 테이블을 하나 만들어야 할수도...)

[ezcolin2]

고생하셨습니다!
우선 현재로는 브라우저가 달라져서 로그아웃 처리 되는 것은 어쩔 수 없을 것 같네요.
그리고 개인적으로 refresh token을 redis에 저장하는 것도 좋을 것 같네요