👀 1. Problem Statement, 문제 상황
이번 프로젝트 진행을 하면서 회원에 대한 파트를 담당하게 되었고, Web IDE 프로젝트 구현의 요구사항대로 회원가입 및 로그인 기능 구현과 마이페이지 사용자 정보 관리를 구현하게 되었다.
SpringSecurity와 JWT를 처음 학습하고 구현할 때, 여러 필터를 커스텀하여 사용하는 과정에서 혼란이 있었다.
특히, 액세스 토큰만을 사용했을 때의 한계점과 클라이언트 측에서 리프레시 토큰이 사라지는 이슈가 있었다.
🔥 2. Problem Analysis, 문제 분석
- 액세스 토큰의 한계점:
- 액세스 토큰만 사용하면 탈취 시 보안 위협이 크고, 유효기간을 짧게 설정하면 사용자 경험이 저하된다.
- 리프레시 토큰 도입 후 문제점:
- 리프레시 토큰을 RDB에 저장했을 때, DB 접근 빈도가 높아져 성능 저하와 리소스 소모가 발생한다.
- 클라이언트 측 리프레시 토큰 이슈:
- 클라이언트에서 리프레시 토큰이 사라지는 문제는 SameSite와 Secure 설정 부족과 관련이 있었다.
🔎 3. Solution Approach, 해결 과정
- 액세스 토큰의 한계 개선:
- 액세스 토큰의 만료 시간을 짧게 설정하여 탈취 위험을 감소시키고, 리프레시 토큰을 도입하여 보안을 강화하면서 사용자 경험을 개선했다.
- 리프레시 토큰 관리 최적화:
- 리프레시 토큰을 RDB 대신 Redis에 저장하여 DB 접근 빈도를 줄이고 성능을 최적화했다.
- Redis의 TTL 설정을 통해 리프레시 토큰의 자동 만료를 통해 효율성을 향상했다.
- 클라이언트 측 리프레시 토큰 전달 문제 해결:
- WebConfig 설정을 통해 API 접근을 허용하여 CORS 문제를 해결했다.
- SameSite와 Secure 설정을 통해 쿠키에 담긴 리프레시 토큰이 클라이언트 측으로 전달되도록 했다.
📊 4. Outcome and Results, 결과 및 성과
액세스 토큰과 리프레시 토큰을 사용하여 인증 및 인가 시스템을 구축하고, 리프레시 토큰을 Redis에 저장하여 DB 접근 빈도를 줄여 성능을 최적화했다.
또한 WebConfig와 핸들러 커스텀을 통해 CORS 문제를 해결했다.
그러나 서버에서 전달하는 쿠키가 클라이언트에 전달되지 않는 문제를 해결하지 못했다.
이는 현재 배포 환경이 HTTP로 되어 있어 쿠키 설정에서 SameSite와 Secure를 설정했지만, HTTPS 배포가 필요하기 때문이었다.
이로 인해 리프레시 토큰과 Redis 사용을 도입하지 못하게 되었다.
✍️ 5. Lessons Learned and Future Plans, 교훈 및 향후 계획
이번 프로젝트를 통해 리프레시 토큰을 도입한다고 해서 보안이 완벽히 보장되는 것은 아니며, 리프레시 토큰에도 한계가 존재한다는 것을 알게 되었다.
특히, 리프레시 토큰이 탈취당했을 경우 서버 측에서 대응이 어렵다는 점을 알았다.
이에 대한 전략으로 액세스 토큰 재발급 시 리프레시 토큰도 함께 재발급하는 1회용 발급 방안을 고려해 봤지만, 이 역시도 XSS 공격에 취약하다는 문제를 발견했다.
내가 사용한 방식인 http only 속성을 통해 쿠키로 리프레시 토큰을 발급하는 방법은 JS에서 토큰에 접근할 수 없어 XSS 공격을 예방할 수는 있지만, CSRF 공격에는 취약하다는 문제를 발견했다.
따라서 향후 인증 및 인가를 구현한다고 하면, 웹 서비스는 세션을 통해서 보안을 챙기고, 모바일의 경우 해킹이 상대적으로 어려우므로 토큰 방식을 사용해서 구현을 해볼 생각이다.
이번 경험을 통해서 인증 및 인가에 대해 조금이나마 이해를 할 수 있었고, 보안과 관련된 문제를 더 면멸히 검토해 볼 필요가 있다고 생각이 들었다.
'7️⃣ 럭키세븐: 트러블 슈팅' 카테고리의 다른 글
| 🎨 D’ART 배포 트러블 슈팅 (0) | 2024.07.17 |
|---|
