서론
이번 프로젝트를 통해 세션, JWT, 쿠키 등 다양한 방식으로 인증 및 인가를 공부하고 적용해보는 시간을 가졌다. 결론적으로, 보안과 UX는 트레이드 오프 관계에 있다. 보안성이 높아지면 사용자 경험은 그만큼 떨어지게 되고, 사용자 경험을 높이려면 어느 정도 보안에 타협이 필요하다. 이번 글에서 공부한 내용을 정리하고 프로젝트를 마무리하고자 한다.
세션의 장점과 단점
스프링 시큐리티의 폼 로그인은 기본적으로 세션 기반 인증이다. 사용자가 로그인하면 시큐리티 컨텍스트에 정보가 올라가며, 이를 통해 권한을 부여받는다.
장점
- 세션 기반으로 인증 정보를 서버에 저장하여 관리할 수 있다.
단점
- 서버가 많아질 경우, 세션 스토리지의 키 값이 혼동되어 암호화된 비밀번호 대조가 어려워진다.
- 해결 방법: 로드 밸런싱을 통해 세션 부하를 나누어 사용하는 방법이 있다.
- 세션이 탈취될 경우 보안에 취약할 수 있다.
- 해결 방법: 서버에서 세션을 만료시키는 방식으로 대처할 수 있다.
JWT 토큰의 장점과 단점, 선택한 이유
JWT (Json Web Token)는 서버가 클라이언트에게 인증 정보를 전달할 때 사용되는 토큰으로, 클라이언트는 이를 HTTP 헤더에 포함하여 서버에 요청을 보낸다. 서버는 토큰의 유효성을 검사한 후 요청을 처리한다.
장점
- 상태를 서버에 저장하지 않고 토큰 자체에 정보를 담는다.
- RESTful한 HTTP 성질에 부합하는 회원 관리 전략으로 적합하다.
선택 이유
- 세션 기반의 단점을 해결할 수 있으며, Access Token과 Refresh Token을 통해 사용자 경험도 고려할 수 있어 JWT 방식을 선택했다.
기본 흐름
Spring Security는 애플리케이션의 보안을 담당하는 필터 기반 프레임워크로, 모든 HTTP 요청은 필터 체인을 통과하여 사용자 인증과 권한 부여가 이루어진다.
- Authentication Provider가 Authentication 객체를 생성하여 반환하며, 이는 시큐리티 컨텍스트에 올라가서 인가 과정을 진행한다.
- DaoAuthenticationProvider는 DB에 저장된 회원 정보와 대조하여 인가를 부여한다.
- UsernamePasswordAuthentication은 UserDetailsService를 통해 사용자 객체를 조회하여 UserDetails를 생성하고 반환한다.
이번 프로젝트에서는 JavaMailSender를 사용해 이메일로 토큰이 담긴 URI를 생성하고, 이메일 링크를 통해 토큰으로 JWT를 발급하여 Access Token과 Refresh Token을 부여했다. OAuth를 통해 인증한 사용자 역시 자사의 Access Token과 Refresh Token을 부여하여 책임 소재를 분명하게 했다.
JWT와 쿠키
JWT는 쿠키에 담겨있고, Spring Security는 세션 기반으로 작동하므로, 이를 통합하기 위해 JWT Request Filter를 구현하여 쿠키에서 JWT를 가져오는 로직을 생성했다. Refresh Token은 DB 부하를 고려하여 쿠키에 저장하였으나, 이로 인해 탈취 위험이 있을 수 있음을 염두에 두었다.
결론
이번 프로젝트를 통해 JWT, Spring Security, Cookie, Session 등 인증과 인가 방식의 동작 원리를 학습하였다. 리프레시 토큰을 효율적으로 관리하는 방법에 대한 추가 학습이 필요하다고 느꼈으며, 기회가 된다면 OAuth 사용자와 다른 인증 방식을 분기하여 결합도가 낮은 리팩토링을 진행할 예정이다.
