[Spring/Oauth2] 회원가입 할 때, 소셜 Refresh_token을 따로 둔 이유

1. 왜 소셜 Refresh_token을 고민하게 되었을까?

최근 회원가입과 로그인 기능을 구현하면서, 소셜 로그인을 지원할 경우 Refresh Token을 어떻게 관리해야 할지 고민하게 되었다. 보통 Refresh Token은 로그인 상태를 유지하는 용도로 사용된다고 알고 있었지만, 소셜 로그인에서는 조금 다른 역할을 한다는 것을 알게 되었다.

일반적으로 우리가 구현하는 앱의 Refresh Token은 사용자의 로그인 상태를 유지하기 위해 사용된다. 하지만 소셜 로그인에서 제공하는 Refresh Token은 로그아웃(계정 연결 해제) 과정에서 필요하며, 이를 잘못 관리하면 불필요한 보안 리스크를 초래할 수도 있다.

이런 고민 끝에 소셜 Refresh Token을 별도로 관리하는 것이 좋다고 결론을 내리게 되었다.

---

2. 왜 소셜 Refresh_token을 별도로 관리해야 할까?

공부하면서 얻은 내용을 정리해 보면, 소셜 Refresh Token을 별도로 관리하는 것이 더 적절한 이유는 다음과 같다.

1. 소셜 Refresh Token은 로그인 유지가 아닌, 계정 연결 해제 시 필요

• 기존 앱 자체의 Refresh Token은 로그인 유지 목적이지만, 소셜 Refresh Token은 계정 연결을 해제할 때 필요하다. 목적이 다르므로 분리하는 것이 좋다.

2. 앱 자체의 Refresh Token과 목적이 다름

• 기존 앱에서 관리하는 Refresh Token은 자체 인증 시스템에서 사용하는 것이고, 소셜 Refresh Token은 외부 서비스의 인증을 위한 것이다. 분리하여 관리하면 유지보수도 쉬워진다.

---

3. 결론: 소셜 Refresh Token은 별도의 테이블로 관리하는 것이 최선이다!

이러한 이유들로 인해, 최종적으로 소셜 Refresh Token을 별도의 테이블에 저장하는 방식으로 정리했다.

• 일반적인 로그인과 관련된 Refresh Token은 기존 방식대로 관리
• 소셜 로그인에서 발급된 Refresh Token은 필요할 때만 저장하고, 암호화하여 보관
• 계정 연결 해제 시에만 사용되므로, 장기간 보관하지 않고 필요할 때만 활용

이렇게 설계함으로써 보안성과 유지보수성을 높일 수 있었다.

아직 배울 것이 많지만, 이렇게 직접 고민하고 정리하면서 조금씩 성장해 나가고 있다는 느낌이 든다. 앞으로도 이런 고민 과정을 기록해 나가면서, 더 좋은 구조를 찾아가고 싶다!