Ignore: ✨ Authenticate the Inbound and Exception Interceptor when using the Connect Frame

[psychology50]

작업 이유

스프링 공식 문서의 명세에는 다음과 같이 적혀있습니다.

• 서버 측 세션을 유지하지 않는 애플리케이션이나 인증을 위해 헤더를 사용하는 것이 일반적인 모바일 애플리케이션에선 쿠기 기반 세션이 항상 적합하지는 않다.
• RFC 6444에선 "WebSocket hand-shake 중에 서버가 클라이언트를 인증할 수 있는 특정 방법을 규정하지 않는다"고 명시되어 있다.
  • 그러나 실제로는 브라우저 클라이언트는 표준 인증 헤더 또는 쿠키만 사용 가능하며, 사용자 지정 헤더를 제공할 수 없다.
  • SockJS에서도 Authorization 헤더를 지정할 수 없음에 대해, 2019년까지 활발한 논의가 이어졌다.
  • 사람들은 대안책으로 Query Parameter로 Access Token을 전달하는 대안을 내놓았지만, 토큰이 서버 로그의 URL과 기록될 수 있다는 고유한 단점이 존재한다.
• HTTP 프로토콜 수준에선 충분한 대안이 없을 테니, STOMP 메시징 프로토콜 수준에서 헤더로 인증하는 방법을 고려해봐라.
  • STOMP Client를 사용해, Connect 시점에 인증 헤더를 전달하고, ChannelInterceptor를 사용해 Server 단에서 해결하는 게 나을 것이다.

Session 기반의 사용자 인증 관리 서비스에선 사용자가 이미 HTTP 수준에서 인증되었음을 보장할 수 있습니다.
하지만 저희는 무상태를 지향하는 JWT 인증 방식을 사용하므로, 이러한 전제가 성립하지 않기 때문에 다음과 같은 경우 인증 과정을 수행해야 합니다.

1. Connect 요청 시
2. Client의 Access token 만료 이후 refresh 요청 마다

작업 사항

인증 기능과 예외 필터 모두 기존의 Security Filter와 매우 흡사합니다.
따라서 딱히 설명할 게 없고, 수정된 것도 애플리케이션 클래스 경로 수정한 게 다라 실제 작업 파일은 2개에 불과합니다.

이해가 안 되는 부분은 질문 주시면 설명 드리겠습니다.

리뷰어가 중점적으로 확인해야 하는 부분

• Principal을 accessor의 setUser()로 설정하면, 웹 소켓이 연결되는 내내 사용자 정보가 헤더에 포함되어 오고 갑니다. 따라서 전역적으로 설정해주고 할 게 딱히 없습니다.

발견한 이슈

• 없음