JWT 기반 사용자 인증 및 보안 토큰 관리: 세션을 넘어 무상태 서버로

웹 애플리케이션의 규모가 커지고 마이크로서비스 아키텍처(MSA)가 표준으로 자리 잡으면서, 전통적인 세션(Session) 기반 인증 방식은 서버 확장성의 한계에 부딪혔습니다. 수많은 서버가 독립적으로 운영되는 환경에서 사용자 상태를 공유하는 것은 기술적으로 복잡하고 비용이 많이 드는 작업이기 때문입니다.

이러한 문제를 해결하기 위해 도입된 핵심 기술이 바로 JWT(JSON Web Token)입니다. eleslog.work 아키텍처 설계의 기반이 된 JWT 인증 시스템의 원리와, 보안을 타협하지 않으면서도 효율적인 토큰 관리 전략을 심층 분석합니다.

1. 세션(Session) 인증의 한계와 JWT의 등장

전통적인 세션 방식은 서버가 사용자의 로그인 정보를 메모리나 데이터베이스에 유지해야 합니다. 하지만 다음과 같은 상황에서 한계가 발생합니다.

• 서버 확장성(Scalability): 서버를 늘릴 때마다 세션 정보를 공유하기 위해 별도의 공유 저장소(Redis 등)를 구축해야 합니다.
• 모바일 앱 대응: 쿠키 기반 세션은 웹 브라우저가 아닌 환경에서 취급하기 까다로운 경우가 많습니다.

반면, JWT는 무상태(Stateless) 지향적입니다. 인증에 필요한 모든 정보를 토큰 스스로가 담고 있는(Self-contained) 방식이기에, 서버는 토큰의 유효성만 검증할 뿐 별도의 상태를 유지할 필요가 없습니다. 이는 서버 부하를 줄이고 유연한 확장을 가능하게 합니다.

2. JWT의 구조: Header, Payload, Signature

JWT는 마침표(.)로 구분된 세 부분의 문자열로 이루어져 있습니다.

Header (헤더)

토큰의 타입(JWT)과 사용된 해싱 알고리즘(HS256, RS256 등)을 명시합니다. 이 정보는 토큰 검증 시 어떤 알고리즘을 사용해야 할지 서버에 알려줍니다.

Payload (페이로드)

토큰에 담을 정보인 '클레임(Claim)'이 들어있습니다. 사용자의 ID, 권한, 토큰 만료 시간 등을 포함합니다. 주의할 점은 이 데이터가 Base64로 인코딩만 되어 있을 뿐 암호화된 것이 아니라는 사실입니다. 누구나 디코딩할 수 있으므로 비밀번호와 같은 민감한 정보는 절대 포함해서는 안 됩니다.

Signature (서명)

헤더의 인코딩 값과 페이로드의 인코딩 값을 서버만 알고 있는 'Secret Key'로 결합하여 생성합니다. 이를 통해 토큰이 전송 과정에서 위변조되지 않았음을 증명합니다.

3. 보안 전략 1: Access Token과 Refresh Token의 분리

JWT의 가장 치명적인 약점은 "한 번 발급되면 만료 전까지 서버가 제어하기 어렵다"는 것입니다. 이를 해결하기 위해 이중 토큰 체계를 구축하는 것이 필수적입니다.

이 방식은 설령 Access Token이 탈취되더라도 공격자가 사용할 수 있는 시간을 극도로 제한하며, 사용자는 재로그인 없이 서비스를 지속할 수 있게 해줍니다.

4. 보안 전략 2: 토큰 저장소 선택 (LocalStorage vs Cookie)

클라이언트에서 토큰을 어디에 저장할지는 보안의 핵심 쟁점입니다.

• LocalStorage: 접근이 쉽지만 XSS(Cross-Site Scripting) 공격에 노출될 경우 자바스크립트로 토큰을 탈취당할 수 있습니다.
• HttpOnly Cookie: 자바스크립트가 쿠키에 접근할 수 없도록 차단하여 XSS로부터 토큰을 보호합니다. 하지만 CSRF(Cross-Site Request Forgery) 공격에 취약해질 수 있으므로, SameSite=Strict 옵션을 반드시 함께 적용해야 합니다.

5. 고급 구현: Refresh Token Rotation (RTR)

보안성을 극대화하기 위해 Refresh Token Rotation 기법을 고려해야 합니다. 이는 Access Token을 재발급받을 때마다 사용된 Refresh Token도 폐기하고 새로운 Refresh Token을 발급하는 방식입니다.

만약 이미 사용된(폐기된) Refresh Token으로 접근이 시도된다면, 서버는 토큰 탈취를 의심하고 해당 유저와 연결된 모든 토큰을 즉시 무효화하여 추가적인 피해를 원천 차단할 수 있습니다.

6. 백엔드 구현과 성능 고려사항

JWT 검증은 데이터베이스 조회는 피할 수 있지만, 매 요청마다 서명을 복호화하는 CPU 연산 비용이 발생합니다. 대규모 트래픽 환경에서는 이를 최적화하는 전략이 필요합니다.

// Express.js 환경에서의 간단한 JWT 검증 미들웨어 예시
const jwt = require('jsonwebtoken');

const authenticateToken = (req, res, next) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) return res.sendStatus(401);

  jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, (err, user) => {
    if (err) return res.sendStatus(403); // 토큰이 유효하지 않거나 만료됨
    req.user = user;
    next();
  });
};
        

또한, 블랙리스트(Blacklist) 기능을 통해 로그아웃된 토큰의 접근을 막으려면 Redis와 같은 고성능 인메모리 DB를 활용하여 만료 전의 토큰 식별자를 관리하는 것이 좋습니다.

마치며: 지속적인 보안 업데이트의 중요성

완벽하게 안전한 인증 시스템은 존재하지 않습니다. 하지만 기술적 특성을 명확히 이해하고 JWT의 취약점을 보완하는 관리 전략을 수립한다면, 서비스의 확장성과 보안성이라는 두 마리 토끼를 모두 잡을 수 있습니다.

eleslog.work는 사용자의 소중한 데이터를 보호하기 위해 최신 보안 트렌드를 연구하고 시스템에 반영하고 있습니다. 여러분의 프로젝트에도 오늘 소개한 보안 전략들이 안전한 이정표가 되기를 바랍니다.