웹소켓 연결 JWT 인증 트러블 슈팅

😐정리

- Websocket Handshake요청은 일반적인 HTTP요청을 잡는 HandlerInterceptor에 걸리지 않아 별도의 처리가 필요하다.

- STOMP CLIENT에서 담는 헤더들은 웹소켓 연결 이후 STOMP 연결이 진행될 때부터 사용이 가능하다.

 즉, Handshake Interceptor에서 토큰을 받아 인증을 진행할 수가 없음

 

- ChannelInterceptor 이용하자 -> COMMAND가 CONNECT일 때만 인증 여부 검증하도록 구현 

- 위 방법은 인증을 여러번 진행하지는 않지만 메시지 전송시에도 토큰을 달고 다녀야 해서 전송 비용이 증가함
- 최종 해결책은 토큰을 쿠키로 관리하여 웹소켓 연결 시 동작하는 Handshake Interceptor에서 한번만 검사하도록 한다.  

 

😐웹소켓 이용시 인증이 안되는 문제 

채팅 기능을 구현은 해봤지만 채팅에 인증을 적용해본적은 없었기에 단순하게 생각하여 아래처럼 구현을 했었습니다.

 

HandlerInterceptor를 이용해 검증 및 인증객체 설정을 진행하고 LoginChecking에서 인증 객체를 이용해 로그인 여부를 판단하고 있었습니다. 

    @LoginChecking  // 커스텀 anntation에 AOP적용
    @MessageMapping("/chat/message")
    public void sendMessage(ChatMessageRequest chatMessageRequest) {
        ChatResponse chatResponse = chatService.create(chatMessageRequest);
        messagingTemplate.convertAndSend("/sub/chat-room/" + chatMessageRequest.getChatRoomId(), chatResponse);
    }

 

당연히 안되겠죠..??ㅎㅎㅎ 이유는 몰랐기에 과정을 설명하자면 디버깅을 찍어봤을 때 토큰을 넣었음에도 불구하고 인증 예외가 계속 터지고 있었습니다.

HandlerInterceptor는 HTTP요청에 대한 인터셉터인데 위 요청은 웹소켓 요청이라 가로챌 수가 없었던 것입니다.

 

임시 방편
로그인 체킹을 제거하고 직접 토큰을 검증했습니다.

-> 문제점이 매번 토큰을 검증하게 되겠죠??

@MessageMapping("/chat/message")
public void sendMessage(ChatMessageRequest chatMessageRequest, @Header("Authorization") String accessToken) {
    String ac = JwtUtils.extractBearerToken(accessToken);

    if (ac != null) {
        if (jwtProvider.validateAccessToken(ac)) {
            Authentication authentication = jwtProvider.getAuthenticationByAccessToken(ac);
        }
    }

    ChatResponse chatResponse = chatService.create(chatMessageRequest);
    messagingTemplate.convertAndSend("/sub/chat-room/" + chatMessageRequest.getChatRoomId(), chatResponse);
}

 

😐연결 과정에서 검증하는 방법은 없을까?

매번 토큰을 검증하는 방법이 너무 비효율적이라 느꼈고 연결 과정에서만 검증을 하면 되지않을까? 라는 생각을 했습니다.

 

처음 생각했던 방법은 웹소켓 연결 과정인 Handshake과정에서 검증을 하자! 이 생각에 웹소켓 핸드셰이킹 과정을 인터셉트하는 방법을 찾았습니다. 아래 코드죠
-> 웹소켓 핸드셰이크 이전에는 HTTP Header를 이용할 수 있다고 하여 이 부분에서 검증을 하려고 했습니다.

@Component
@RequiredArgsConstructor
public class WebSocketInterceptor implements HandshakeInterceptor {
    private final JwtProvider jwtProvider;
    @Override
    public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) throws Exception {
        HttpHeaders headers = request.getHeaders();
        String authToken = headers.getFirst(HttpHeaders.AUTHORIZATION);
        return true;
    }

    @Override
    public void afterHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Exception exception) {

}
}

 

😐왜 Header가 NULL값이 뜰까

저는 STOMP를 이용하고 있고 클라이언트 코드가 아래와 같이 작성돼 있었습니다. 클라이언트 쪽에서 토큰이 담긴 것은 log로도 확인을 했습니다. 서버에서 확인이 안되는게 확실했죠

try {
      console.log(">>>  첫 연결 시도 ");

      const client = new Stomp.Client({
        webSocketFactory: () => socket,
        connectHeaders: {
          Authorization: `Bearer ${ACCES_TOKEN}`,
          name: `name`,
          password: `password`,
        },
        heartbeatIncoming: 0,
        heartbeatOutgoing: 0,
      });

..... 이하 내용 생략 .....

 

이유는 제가 위에서 담아놓았던 헤더들은 STOMP 연결을 위한 요청 시 생성되기 때문이었습니다.
STOMP CLIENT를 이용했을 때 연결 과정이 아래와 같았던거죠

 

1. STOMP 클라이언트 생성
2. 웹소켓 연결 시도
3. 웹소켓 핸드셰이크
4. STOMP 핸드셰이크 - 웹소켓 연결이 설정된 후, STOMP 클라이언트는 서버에 STOMP 핸드셰이크 요청을 보냅니다. 이 핸드셰이크 요청에는 STOMP 프로토콜을 사용하기 위한 추가 정보가 포함될 수 있습니다.

(요 시점부터 헤더들 이용 가능)

5. 서버 응답

 

😐ChanelInterceptor를 이용하자 

ChannelInterceptor 는 메세징 요청/응답(InBound, OutBound) 을 가로채 로직을 수행하는 일종의 필터 역할을 수행한다고 볼 수 있습니다.

 

여기서는 STOMP CLIENT에서 담은 connectHeaders를 이용가능합니다. 동시에 STOMP 메시지에는 메시지의 동작을 정의하는 Command(CONNECT, SEND, SUBSCRIBE, MESSAGE 등등) 가 들어있죠 

 

즉, 아래와 같이 CONNECT 시에만 토큰을 검증할 수 있게됐습니다. 

 

@Component
@RequiredArgsConstructor
public class StompInterceptor implements ChannelInterceptor {
    private final JwtProvider jwtProvider;
    @Override
    public Message<?> preSend(Message<?> message, MessageChannel channel) {
        StompHeaderAccessor accessor = StompHeaderAccessor.wrap(message);

        if (StompCommand.CONNECT.equals(accessor.getCommand()))
            validateToken(accessor);

        return message;
    }

    private void validateToken(StompHeaderAccessor accessor) {
        String accessToken = JwtUtils.extractBearerToken(accessor.getFirstNativeHeader(HttpHeaders.AUTHORIZATION));

        if (accessToken == null)
            throw new ForbiddenException(ErrorCode.NOT_LOGIN);

        jwtProvider.validateAccessToken(accessToken);

    }
}

 

😐문제점

검증을 매번 하진 않을 수 있게됐지만 사실  메세지에 토큰이 항상 담기기 때문에 전송비용은 커질 수 있습니다. 저는 websocket연결을 컨트롤할 수 없으니 연결 전에 HTTP요청으로 인증여부를 검사하려고 했었습니다. CORS를 막아놓는다면 프로젝트에서 의도한대로만 웹소켓에 접근할 수 있으니 유일한 경로가 되는거죠 이 또한 문제점은 존재합니다.

 

Channel Interceptor 이용
장점 : 메시지를 보내기 직전에 동작하기 때문에 보안성이나 인증 외에 검증 로직을 수행하기 좋음

단점 : 메시지에 매번 토큰이 담겨서 전송됨 

 

연결전 HTTP요청으로 인증 여부 확인(CORS설정으로 접근 경로를 차단)

장점 : 메시지를 보낼 때 매번 토큰을 담지 않아도됨
단점 : 이론상 막았지만 확실하게 막힌지 잘 모르겠음 + 디테일한 검증 불가능

 

😐해결책

Channel Interceptor까지 인증을 미뤘던 이유는 웹소켓 연결 Handshake 요청이 STOMP CLIENT 라이브러리에 의해 처리되기 때문에 토큰을 직접 담기 어려워서 입니다.

즉, 쿠키를 사용한다면 굳이 수동으로 담을 필요가 없어집니다. 저는 HandshakeInterceptor에서 쿠키로 전달된 토큰을 꺼내 검증을 진행했습니다.