JWT (JSON 웹 토큰)
쉽게 풀면
놀이공원 손목밴드를 떠올려 보세요. 입구에서 직원이 손목밴드를 채워주면, 이후 다른 놀이기구를 탈 때마다 직원 명부를 다시 뒤질 필요 없이 손목밴드만 보여주면 됩니다. 손목밴드에는 위조 방지 표시가 있어서 아무나 만들 수 없죠. JWT도 똑같은 원리입니다. 사용자가 로그인하면 서버가 "이 사람은 인증된 사용자"라는 정보를 담아 서명이 붙은 토큰(손목밴드)을 발급합니다. 이후 사용자는 요청할 때마다 이 토큰을 제시하고, 서버는 매번 데이터베이스를 조회하지 않고 서명만 확인해서 진짜인지 판단합니다. 덕분에 여러 서버로 나뉜 시스템에서도 별도의 세션 저장소 없이 사용자의 인증 상태를 빠르게 확인할 수 있습니다.
왜 중요한가
웹 서비스가 여러 대의 서버로 분산되거나 마이크로서비스 구조로 나뉘면, 요청마다 중앙 세션 저장소를 조회하는 방식은 지연과 병목의 원인이 됩니다. JWT는 인증 정보를 토큰 자체에 담아 서명 검증만으로 신뢰성을 확인할 수 있게 해주므로, 분산 시스템·API 보안·서비스 간 인증(SSO) 설계를 다루는 컴퓨터과학 논문에서 자주 등장하는 개념입니다. 특히 클라우드 네이티브 아키텍처, 모바일 백엔드, IoT 기기 인증처럼 상태를 서버에 두기 어려운 환경에서 인증 방식을 비교하거나 설계할 때 기준점으로 언급됩니다.
논문에서는 이렇게 쓰입니다
이 문장은 로그인한 사용자에게 1시간 동안만 유효한 JWT를 발급해, 시간이 지나면 다시 로그인해야 한다는 뜻입니다. 시스템 아키텍처나 보안 설계를 다루는 논문에서 인증 방식을 명시할 때 자주 등장합니다.
여러 서비스로 나뉜 시스템에서 각 서비스가 중앙 세션 서버에 의존하지 않고도 요청이 인증된 사용자로부터 왔는지 독립적으로 확인할 수 있다는 뜻입니다. 분산 시스템이나 클라우드 아키텍처 연구에서 인증 구조를 설명할 때 흔히 쓰이는 표현입니다.
토큰 안에 단순히 신원뿐 아니라 어떤 권한을 가진 사용자인지까지 담아, 요청이 올 때마다 접근 가능 범위를 함께 판단했다는 뜻입니다. 보안이 중요한 응용 분야(의료, 금융 등)의 시스템 설계 논문에서 접근 제어 메커니즘을 설명할 때 볼 수 있는 예입니다.
조금 더 깊게 보면
JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분이 점(.)으로 이어진 구조를 가지며, 각 부분은 Base64Url로 인코딩되어 있습니다. 페이로드에는 사용자 식별자나 권한 같은 정보(클레임, claim)가 담기는데, 이는 암호화된 것이 아니라 인코딩된 것이므로 누구나 디코딩해 내용을 볼 수 있습니다. 실제로 위변조를 막는 것은 서명 부분으로, 서버가 비밀키(또는 공개키 방식이라면 개인키)로 헤더와 페이로드를 서명해 만들며, 서버는 이후 이 서명을 재계산해 일치 여부만 확인하면 됩니다. 논문에서 JWT의 보안성을 다룰 때는 대체로 서명 알고리즘의 선택(대칭키 방식인 HMAC 계열과 비대칭키 방식인 RSA·ECDSA 계열의 차이), 토큰 만료 및 갱신(리프레시 토큰) 전략, 그리고 페이로드에 민감 정보를 담지 않아야 한다는 점이 함께 논의됩니다.
주의할 점
JWT는 한번 발급되면 만료되기 전까지 서버가 강제로 무효화하기 어렵다는 한계가 있습니다. 로그아웃하거나 토큰이 유출돼도 유효기간이 끝날 때까지는 여전히 사용될 수 있어, 유효기간을 너무 길게 설정하면 보안 위험이 커집니다. 인증 위임 방식 전체를 가리키는 OAuth (인증 위임 프로토콜)와 혼동하기 쉬운데, OAuth는 프로토콜이고 JWT는 그 안에서 쓰이는 토큰 형식 중 하나입니다.