JWT는 왜 사용할까?

GPT 요약

My-Books 프로젝트에서 세션 불일치 문제를 해결하기 위해 JWT 인증을 도입했습니다.
JWT는 서버 자원 없이 확장성이 높고 MSA에 적합합니다.
사용 시 보안에 유의해야 합니다.

My-Books 프로젝트에서의 경험을 다룬 글입니다

기존에 진행했던 토이 프로젝트에서는 Cookie-Session 기반으로 인증/인가를 구현했기에, My-Books에서도 동일한 방식을 적용하려 했지만 MSA 환경이라는 특수성 때문에 다음과 같은 문제에 직면했습니다.

세션 불일치 문제

Cookie-Session 방식은 세션에 유저 정보를 담아두고 쿠키에 세션 id를 기입하는 방식입니다.
쿠키의 경우 사용자가 HTTP 요청 시 자동으로 헤더에 담겨 서버로 전송되기 때문에 간단하고 직관적으로 구현이 가능하며 세션 데이터는 서버에 저장되므로 보안성도 챙긴 방식입니다.

여기서 중요한 건 세션 데이터는 서버에 저장된다는 것입니다. 세션 자체가 서버 자원의 일부이기 때문에 서버에 종속적임을 의미하고
이는 MSA 환경 혹은 Sacle-Out으로 서버가 구성돼있는 경우에 서버 간 세션 불일치 문제가 발생합니다.

사용자가 A 서버에서 로그인을 한 후 B 서버로 라우팅 된다면 세션에 유저 정보가 존재하지 않기 때문에
다시 로그인을 하라는 요청을 보낼 것입니다.

이는 사용자의 경험을 저하시키고 서버 측에서는 불필요한 데이터를 중복으로 갖게 되는 문제를 발생시킵니다.
또한 사용자의 트래픽이 몰려 요청을 분산시켜야 하는 경우에 확장성에 문제또한 발생합니다.

세션 불일치

이러한 문제는 세션을 모아주는 Session Clustering, 혹은 동일한 서버로만 요청을 주고받는 Sticky Session으로 해결이 가능하지만
추가적인 작업이 필요해 복잡도가 올라가기 때문에 또 다른 제약이 생기게 됩니다.

Session  Clustering

Sticky Session

해결법

따라서 저는 JWT를 기반으로 한 인증/인가 방식을 도입했습니다.
JWT는 Json Web Token의 약자로 Json 포맷의 데이터를 인코딩하여 사용하는 토큰입니다.

JWT 구조

방식은 Cookie-Session과 동일합니다.

1. 사용자가 로그인 시 JWT 토큰을 발급
2. 쿠키로 JWT 내려줌
3. 사용자의 요청에 JWT 정보를 헤더에 담아 보냄

여기서 차이점은 JWT는 그 자체로 사용자의 상태와 권한 정보를 포함하고 있다는 것입니다.

JWT를 디코딩시 유저정보가 나오는 모습

서버의 자원인 세션을 사용할 필요가 없으며 각각의 서버에 JWT를 검증하고 읽어내는 코드만 추가되면 됩니다.

오픈소스인 auth0 사용 간단한 구현

서버에 종속되지 않기 때문에 자유롭게 Scale-Out 하거나 Load Balancing을 통해 요청을 분산시켜도 문제가 발생하지 않습니다.
또한 앞서 설명한 Session Clustering과 Sticky Session보다 훨씬 낮은 복잡도를 가지며 직관적입니다.

만약 모든 요청이 몰리는 Gateway 서버를 둔다면 JWT 관련 코드를 백서버와 아예 분리시켜 관리가 가능하며
My-Books에서도 동일한 방법을 사용 중입니다.

My-Books프로젝트 아키텍처

이외에도 서버의 자원인 세션을 사용하지 않기 때문에 서버의 자원을 아낄 수 있다는 이점도 존재합니다.

다만 주의할 것은 JWT는 그 자체로 암호화된 무언가가 아니라 그냥 인코딩한 문자열이라는 것입니다.
따라서 사용 시 고려해야 할 사항이 많으며 이와 관련해 추가적인 링크를 남깁니다.

JWT 안전성 개선기