Real JWT (Feat. 쿠키 세션)

신입 개발자의 포트폴리오의 기본 스택으로 포함되는 것 중의 하나는 JWT를 활용한 토큰 기반 인증 이라고 할 수 있다. 이미 수 많은 기업에서는 마이크로서비스 아키텍처와 쿠버네티스 도입을 시도하다가 포기한 경우가 많을 것이다. 심지어 마이크로서비스 아키텍처를 고려하다가 오히려 모놀리식 아키텍처로 전환하는 사례도 찾을 수 있다.

오늘은 JWT 토큰을 사용하여 사용자 인증을 유지하는 것에 대해서 이야기 해보고자 한다. 미리 말하자면, 실무에서 JWT 토큰을 사용해본 경험이 없으며 크지 않은 시스템을 개발하고 있는 테크 리더로써의 생각이다.

과연 쿠키 세션보다 효율적인가 🤔

사용자 인증에 JWT를 도입하는 경우를 보면 대부분 세션에 대한 비효율성을 이야기한다. 시스템의 규모와 트래픽이 많아지는 경우 세션을 조회하는 과정에서 과부하를 일으킬 가능성이 있어보이는 건 사실이고 세션 클러스터링을 수행한다하더라도 중앙화 되어버리는 구조로 인해 관리 포인트가 늘어날 순 있다. 서버가 세션 유지를 위해 담당하는 부하 뿐만 아니라 고려해야할 것은 인프라에 대한 비용일지 모른다. AWS 환경에서 HTTPS API 비용을 줄이는 방법도 공유되는 것처럼 작은 패킷의 차이도 생각보다 많은 비용이 늘어날 수 있다는 이야기다.

JWT의 가장 큰 단점은 JSON으로 구성된 문자열을 Base64 인코딩하여 구성한다는 것이다. 그리고 보안적인 관점이 높을수록 키 길이가 긴 RSA 또는 ECC 키로 구성된 공개키 기반의 서명을 하게 될 것이다. 그리고 올바른 키로 서명할 수 있도록 JWK도 제공하게 될 것이다. 아무튼 보안으로 인해 키 길이가 길어질수록 Base64 인코딩 특징으로 인해 HTTP 통신 패킷의 사이즈가 기하급수적으로 커질 수 있다는 말이다. 그리고 이것은 요청과 응답 페이로드 크기로 인해 막대한 트래픽 비용이 발생할 수 있다는 것과 동일하다.

보안 지식을 이해할 수 있는가 😵

JWT에 대한 상세 구현은 개발자의 역량에 있기에 여러가지 보안 지식이나 관점이 필요하다. 브라우저와 서버 간 통신을 위해서는 반드시 HTTPS 연결을 통해 패킷을 안전하게 보호해야한다. 기본적인 암호화 통신은 토큰을 안전하게 보호할 수 있는 최소한의 방어이기 때문이다. 언어마다 개발자들을 위한 JWT 관련 라이브러리들이 있지만 그것을 활용해서 제대로 활용하려면 보안 지식을 이해하고 있어야 한다. HS256과 RS256의 차이를 알기 위해서는 공개키 기반 암호화에 대한 기본 지식이 필요하다. 개인적인 견해로는 신입 개발자 뿐만 아니라 주니어 개발자들이 HTTPS를 이해하는 것조차도 쉽지 않다고 생각한다.

개발자 커뮤니티인 오키 사이트를 보더라도 HTTPS를 사용하고 있지만 JWT로 구성된 액세스 토큰과 리프래시 토큰을 쿠키로 관리함에도 Secure 와 SameSite 속성을 제대로 적용하지 않음을 볼 수 있다. 이것은 시스템 보안 가이드라인에 따라서 위배된 애플리케이션이라고 검출되어 조치 대상이 될 수 있는 중요한 부분이다.

실제로 신입 개발자 인터뷰를 진행하다보면 토큰 기반 인증을 구현하더라도 세션에 대한 이해와 경험이 부족하다고 느껴질 만큼 제대로 된 답변을 하지 못하는 경우가 상당하다. 심지어 OAuth 소셜 로그인을 별도로 사용했음에도 불구하고 토큰은 JWT만 있다고 말하는 케이스도 있었다.

이러한 부분들을 통해 엄청 높은 실력의 역량을 보유한 신입이 아니고서야 거의 모든 신입 웹 개발자들은 전통적인 세션에 대한 경험을 쌓고 세션에 대한 문제점을 이해하는 것이 더 중요하지 않을까 생각해본다. 개인적으로는 세션을 활용한 프로젝트를 포트폴리오로써 보고싶다. JWT를 활용한 토큰 기반 인증이 넘쳐나는 포트폴리오들 속에서 오히려 경쟁력이 있어보이는 것은 가장 단순한 세션을 사용한 것이 아닐까?…