[Spring Security] 4. CSRF API 엔드포인트 구현과 'Double Submit Cookie' 패턴의 완성

CSRF 토큰의 저장소와 처리기를 모두 SPA 환경에 맞게 설정했다. 서버는 클라이언트의 요청을 검증할 준비를 마친 셈이다.

그런데 한 가지가 빠졌다. 클라이언트, 즉 SPA는 어떻게 최초의 CSRF 토큰을 얻을 수 있을까? 이 마지막 퍼즐 조각인 토큰 발급 API 엔드포인트를 구현하고, "Double Submit Cookie" 패턴의 전체 흐름을 정리한다.

왜 SPA는 전용 토큰 발급 API가 필요한가

SPA는 최초에 index.html과 같은 정적 리소스를 로드한 후, 자바스크립트를 통해 동적으로 페이지를 그려나간다. 이 과정에서 CSRF 토큰이 자동으로 발급된다고 보장할 수 없다.

따라서 SPA가 모든 로딩을 마친 후, "CSRF 토큰을 발급해 달라"고 명시적으로 요청할 수 있는 공식적인 창구가 필요하다.

API 구현 및 'Double Submit Cookie' 패턴의 완성

AuthController.java에 토큰 발급 API를 구현한다.

// AuthController.java
@RestController
@RequestMapping("/api/auth")
public class AuthController {

    @GetMapping("csrf-token")
    public ResponseEntity<Void> getCsrfToken(CsrfToken csrfToken) {
        return ResponseEntity.noContent().build();
    }
}

'Double Submit Cookie' 패턴 최종 흐름도

심층 분석 - Spring MVC의 HandlerMethodArgumentResolver

getCsrfToken(CsrfToken csrfToken) 처럼, 컨트롤러 메서드 파라미터를 선언하는 것만으로 어떻게 필요한 객체가 자동으로 주입될까? Spring MVC의 ==HandlerMethodArgumentResolver== 라는 메커니즘 덕분이다.

• 역할 '인자 해석기'. 컨트롤러 메서드가 호출되기 전에, 메서드가 필요로 하는 파라미터들을 해석하고 준비해주는 역할을 한다.
• 동작 Spring Security는 CsrfToken 타입의 파라미터를 위한 CsrfTokenArgumentResolver를 사전에 등록해 두었다. 이 해석기는 요청이 들어오면 CsrfToken 파라미터를 인지하고, CsrfTokenRepository를 통해 토큰 객체를 가져오거나 생성하여 메서드에 주입해 준다.

이것으로 총 4편에 걸친 Spring Security CSRF 방어 설정 시리즈를 마친다.