socket io 1:1 채팅 구현 (2)jwt 토큰 전달

1:1 채팅을 구현하며 두번째로 생각이 많이 되었던 부분은 jwt를 통한 토큰 전달 부분이었다. 기존 공통 jwt strategy와 guard를 이용해 채팅을 하나씩 구현해나가는 중 jwt쪽에서 계속적으로 에러가 발생했다. 처음에는 원인을 찾지 못했는데, 하나 둘 찾아보던 중 socket 같은 경우 jwt를 전달하는 방식이 다르다는 것을 알게 되었다. 

 

HTTP와 WebSocket의 차이점

• HTTP : 요청-응답 방식으로 동작. 클라이언트가 서버에 요청을 보내고, 서버는 요청에 대한 응답을 반환. 이 과정에서 클라이언트는 요청 헤더에 JWT 토큰을 포함시킬 수 있으며, 서버는 이 토큰을 검증하여 사용자의 인증 상태를 확인할 수 있다.
• WebSocket :  클라이언트와 서버 간에 지속적인 연결을 유지하는 프로토콜. 연결이 설정되면, 추가적인 요청 없이 양방향 통신 가능. 이 때문에, WebSocket 연결이 설정된 후에는 HTTP 헤더와 같은 방식으로 데이터를 전송 불가능.
  -> WebSocket 연결 시 JWT 토큰을 안전하게 전달하는 방법을 고려 필요

 

WebSocket에서 JWT 토큰 전달 방법

webSocket에서 JWT 토큰을 전달하는 방법을 찾아보았다.

1. Query String 또는 URL Parameter 사용

장점:

• 구현의 간편함: 가장 쉽게 구현할 수 있는 방법으로, 클라이언트에서 토큰을 URL에 추가하고 서버에서 이를 추출하여 검증한다.
• 서버 로깅: 많은 서버 로깅 시스템에서 URL을 기록하기 때문에, 클라이언트가 어떤 토큰으로 접속했는지 쉽게 추적할 수 있다.

단점:

• 보안 취약성: URL에 포함된 토큰은 쉽게 노출될 수 있어, 브라우저 히스토리, 서버 로그, 중간자 공격 등 다양한 방식으로 토큰이 탈취될 위험이 있다.
• 토큰 길이 제한: URL의 길이 제한으로 인해, 매우 긴 JWT 토큰을 사용할 경우 문제가 발생할 수 있다.

2. Custom Authentication Event 사용

장점:

• 보안 강화: 토큰이 URL에 노출되지 않고, WebSocket 연결 후 안전하게 전송. 이는 토큰 탈취의 위험을 줄여준다.
• 유연성: 인증 이벤트 외에도 다른 이벤트들을 추가적으로 사용할 수 있어, 확장성 있는 구조를 구현할 수 있다.

단점:

• 구현 복잡성: 추가적인 이벤트 핸들링 로직이 필요하며, 클라이언트와 서버 모두에서 이를 구현해야 한다.
• 지연 시간: WebSocket 연결이 수립된 후 별도의 이벤트를 통해 토큰을 전송하므로, 인증 과정에서 약간의 지연이 발생할 수 있다.

3. Upgrade Request Headers 사용

장점:

• 보안성: HTTP 헤더를 통해 토큰을 전송하므로, 토큰이 URL에 노출되지 않아 중간자 공격에 대한 안전성을 높여준다.
• 일관성: 기존의 HTTP 기반 인증 방식과 유사하여, WebSocket을 사용하더라도 기존의 인증 로직을 쉽게 재사용할 수 있다.

단점:

• 헤더 접근의 어려움: 일부 WebSocket 클라이언트에서는 HTTP 헤더를 직접 설정하는 것이 어려울 수 있다. 특히 브라우저 기반의 WebSocket에서는 헤더 설정이 제한적이다.
• 초기 연결 실패: WebSocket 초기 연결 시 토큰이 올바르게 전달되지 않으면 연결 자체가 실패할 수 있다.

 

우선 프로젝트 기간이 짧아 구현부터 먼저하자는 느낌으로 쿼리를 통한 jwt 토큰 전달 방식을 선택해 구현하였다. 하지만 아무래도 보안문제가 있다보니, 추후 코드를 리팩토링하는 과정에서 'Upgrade Request Headers'를 사용하는 것을 해당 글에 다시 정리를 해보려 한다.