회원기능 구현

전술했듯, 웬만한 웹앱에는 회원기능이 무조건 포함되어 있다. 그리고 스프링 프레임워크에서는 스프링 시큐리티라는 인증 관련 도구를 제공한다. 우선은 왜 써야할 지에 대하여 간략하게 회고하고 기능 구현과 관련된 트러블 이슈를 소개해볼 예정(물론 얘가 제일 많았다...)

웹개발에서의 보안 세팅은 결국 그 구현 방법이 다양하고 무궁무진하기 때문에 어느 하나가 정답이라고 딱 말할 수는 없겠지만, 나름의 트러블 슈팅 및 고민 과정을 거쳐가면서 나의 선택 근거를 하나씩 정리할 예정.

1. 인증 작업 및 순서

자바의 웹 앱은 기본적으로 Dispatcher Servlet을 지나쳐 controller 단계로 넘어서고 우리가 익히 아는 3계층 플로우를 거쳐 로직을 수행하게 된다. 여기서 말하는 로직이라 함은, 클라이언트에서 요청한 작업 처리일 수도 있고 혹은 서버 자체의 작업일 수도 있다.

이 Dispathcer Servelet을 지나기 전에 거치게 되는 부분이 자바의 Filter 단계인데, 내가 들었던 고민은 인증 처리의 순서를 Dispatcher Servelet 전후 중 어디로 두는 것이었다.

(1) 인증 처리 순서

내 결정부터 말하자면, 자바 표준을 따르는 Filter 단계에서의 처리였다.

인증 작업은 기타 서버 사이드 작업보다 우선되는 단계다. 즉, 3계층 아키텍처의 애플리케이션 단계에서 백엔드 로직이 동작하게 되는 것으로 클라이언트의 요청 작업을 처리하는 것인데, 이 요청 작업이 이뤄지기 위한 전제 조건이 인증이기 때문에 요청 작업이 이뤄지는 컨트롤러보다 앞전인 필터에서 인증 처리를 진행하는 것이 옳다고 생각했다.

스프링 시큐리티는 필터 체인을 기반으로 다양한 인증 처리를 할 수 있는 도구들을 제공하기 때문에, 회원 인증을 위한 보조 수단으로 스프링 시큐리티를 채택하였다.

(2) 인증 방식

인증 구현의 방식은 기존의 것들을 채택할 수도 있고, 내가 직접 커스터마이징할 수도 있다. 다수 활용되면서 안정성이 상대적으로 보장된 보안 인증 방식인 세션과 JWT 중에 고민하면서 일반 토큰 또한 개념 정리 차원에서 비교하였다.

특징	세션	일반 토큰	JWT
상태 저장	서버	클라이언트	클라이언트
서버 확장성	낮음	높음	높음
보안	서버에 민감 정보 저장, 안전	클라이언트에 민감 정보 저장 주의 필요	페이로드에 민감 정보 저장 금지
유효성 확인	서버에서 세션 ID 확인	서버에서 토큰 검증	서버에서 서명 검증
구현 복잡도	상대적으로 높음	중간	낮음

구현 난이도와 확장성을 고려했을 때는 JWT 방식이 적합하고, 조금 더 강력한 보안을 요구할 때는 세션 방식이 적합하다. 나는 JWT를 선택했는데, 자바의 특성 중 하나인 다형성은 결국 앱의 확장과 유지 보수를 용이하게 하는 근거로써 작동한다.

이것이 정답인 것은 아니지만, 웹 앱의 개발 언어로 자바를 선택하였고 선택 근거에서 향후 앱의 확장을 고려하기 위함이기 때문에 구현 복잡도가 높지 않고 서버의 확장성에 있어 유연하게 적응이 가능한 JWT를 선택 근거로 삼았다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    // CSRF(사이트 간 요청 위조) 설정 비활성화
    // 해당 기능은 람다식으로
    http.csrf(AbstractHttpConfigurer::disable);

    // Security 의 기본 설정인 Session 방식이 아닌 JWT 방식을 사용하기 위한 설정
    http.sessionManagement((sessionManagement) ->
            sessionManagement.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
    );
    
    // ...