콘텐츠로 이동

JWT (서명 토큰)

로그인 결과를 서버가 세션을 저장해 두고 매번 확인하는 방식은, 서비스가 여러 개로 늘면 매번 같은 세션 저장소를 뒤져야 해서 번거로워요. JWT(JSON Web Token)는 인증 결과를 서명된 토큰 한 장으로 주고받아서, 서버가 상태를 저장하지 않아도 되는 형식이에요. 여러 서비스가 같은 검증 방식으로 같은 토큰을 믿고 쓸 수 있어서, 멀티 서비스 환경과 잘 맞아요.

토큰 자체가 곧 "증명서"인 셈이라서, 검증 절차만 공유하면 어느 서비스든 그 증명서를 인정할 수 있어요. 다만 그만큼 토큰을 다루는 책임이 우리 쪽에 있다는 점을 함께 기억해야 해요.

하위 챕터

핵심 개념

토큰의 구조. JWT는 점(.)으로 구분된 세 부분으로 이뤄져요. 헤더(서명 알고리즘), 페이로드(사용자 정보·클레임), 시그니처(서명)입니다.

헤더.페이로드.시그니처

페이로드는 읽는 사람이 base64로 쉽게 볼 수 있어요. 그래서 비밀번호 같은 민감 정보는 절대 넣지 않고, 토큰 자체는 위·변조가 아닌 "서명 검증"으로 신뢰한다는 점을 기억해야 해요.

서명과 검증. 서명 방식에 따라 HS256(하나의 비밀키로 서명·검증, 대칭)과 RS256(개인키로 서명, 공개키로 검증)이 있어요. 공개키/비밀키가 분리되는 RS256은 여러 서비스가 공개키만 나눠 쓰기 좋아서 널리 권장돼요.

검증 쪽에서 헷갈리기 쉬운 지점은 "base64로 읽히니까 누구나 볼 수 있지 않나"라는 생각이에요. 내용은 누구나 읽을 수 있지만, 서명이 유효한지 확인해야 그 토큰을 신뢰할 수 있어요.

상태 없는(Stateless) 인증. 서버가 세션을 저장하지 않아도 되니까, 여러 서비스가 같은 검증 절차만 갖추면 같은 토큰을 공유할 수 있어요. 로그인한 사용자가 웹빌더와 Canvas를 오갈 때도 로그인을 반복할 필요가 없죠.

만료(exp)와 폐기. 토큰에는 만료 시각(exp 클레임)을 넣어 짧게 잡고, 검증할 때 만료를 확인해요. 만료된 토큰은 재사용할 수 없어요. 또 페이로드에 담긴 클레임은 서비스가 권한을 판단하는 재료가 되므로, 어떤 클레임을 넣을지도 함께 설계해야 해요.

사용 사례 / 실제 적용

로그인에 성공하면 발급한 JWT를 여러 제품이 같은 방식으로 검증해요. 사용자는 한 번 로그인해서 받은 토큰으로 웹빌더·Events를 오가고, 백엔드(Spring Security 등)는 각 요청의 토큰 서명을 확인해 권한을 판단합니다.

챙겨야 할 문제가 몇 가지 있어요. 첫째, 토큰을 안전한 곳(쿠키 등)에 보관하고 민감 정보를 넣지 않는 것. 둘째, 토큰이 탈취됐을 때 대응할 수 있게 만료를 짧게 잡고, 필요하면 토큰 폐기 목록(블랙리스트)을 두는 것. 이건 토큰 수명이나 보안 정책에 따라 "확인 필요"인 부분이기도 해요.

더 알아보기