JWT와 보안 토큰 가이드 이미지

‘어쩌다 보니’ 쓰고 있지는 않나요?

현대적인 웹 개발에서 인증의 주역이 된 JWT (JSON Web Token). 워낙 라이브러리들이 훌륭하다 보니 내부 구조를 자세히 몰라도 일단 작동하는 프로그램을 만들 수는 있습니다. 하지만 그러한 ‘어쩌다 보니’ 식의 사용이 때로는 돌이킬 수 없는 보안 구멍을 만들기도 합니다.

“JWT는 결국 무엇을 보호하는 걸까?”, “서명과 해싱은 무엇이 다를까?”
이런 궁금증들을 해소하고, 자신 있게 보안을 이야기할 수 있는 엔지니어가 되어 봅시다.

JWT를 구성하는 ‘3개 파편’의 역할

JWT는 점(.)으로 구분된 세 부분으로 구성됩니다.

  1. Header: ‘어떤 방식으로 서명했는가’를 적어둔 봉투의 겉면.
  2. Payload: ‘누가’, ‘언제까지’ 유효한가를 적어둔 편지 내용.
  3. Signature: 봉투가 중간에 열리거나 내용이 바뀌지 않았음을 증명하는 ‘검인’.

여기서 가장 중요한 점은 **‘헤더와 페이로드는 누구나 읽을 수 있다’**는 것입니다. Base64로 인코딩되어 있을 뿐 암호화된 것이 아니기 때문입니다. 페이로드에 비밀번호나 카드 번호를 넣는 것은 편지 내용을 투명한 비닐봉지에 담아 보내는 것과 같습니다.

신뢰의 핵심: 서명과 해싱

JWT의 진정한 가치는 그 ‘무결성’에 있습니다. 그리고 이를 지탱하는 것이 바로 해싱과 서명입니다.

  • 해싱(Hashing): 데이터의 ‘디지털 지문’을 만드는 작업입니다. (예: “이 데이터라면 반드시 이 값이 나온다”)
  • 서명(Signing): 해시값에 비밀 키로 도장을 찍는 것입니다. 키가 없는 제3자가 페이로드의 글자 하나라도 바꾸면 서명과의 일관성이 깨지고, 즉시 ‘위조품’임이 드러나게 됩니다.

키를 어떻게 배포할 것인가: JWKS의 마법

RSA와 같은 공개키 방식의 인증을 사용할 때, 검증하는 쪽은 어떻게 키를 얻어야 할까요?
이때 사용되는 것이 바로 **JWKS (JSON Web Key Set)**입니다.

서버가 “최신 공개키는 이거야!”라고 웹상에 공개하고, 검증하는 쪽이 이를 자동으로 읽어가는 방식입니다. 이를 통해 시스템 중단 없이 안전하게 키를 주기적으로 업데이트(로테이션)할 수 있습니다.

DevToolKits로 보안을 ‘체감’하기

글로만 이해하기 어려운 개념도 직접 움직여 보면 금방 이해할 수 있습니다.

  • JWT 도구: 내 토큰이 어떤 ‘파편’으로 이루어져 있는지 브라우저 상에서 안전하게 들여다보세요.
  • JWKS 생성기: 키 쌍을 생성하고 실제 어떤 JSON 형식으로 공개되는지 시뮬레이션해 보세요.
  • 해시 생성 도구: SHA-256 등을 사용하여 데이터가 어떻게 ‘지문’으로 변하는지 직접 확인해 보세요.

자주 묻는 질문

HS256과 RS256 중 무엇을 써야 하나요?

토큰을 발급하는 곳과 검증하는 곳이 같다면 HS256(공유 비밀키)으로 충분하며 구현도 단순합니다. 반면 여러 서비스가 검증만 해야 한다면 RS256을 쓰세요. 비밀키는 발급 측만 갖고 공개키를 배포하면 되므로, 검증 측이 유출되어도 토큰을 위조당하지 않습니다.

다운타임 없이 키를 교체하려면 어떻게 하나요?

검증 측이 여러 키를 동시에 받아들이는 상태를 만드는 것이 핵심입니다. 먼저 새 키를 검증 대상에 추가하고(아직 발급에는 쓰지 않음), 충분히 배포된 뒤 발급을 새 키로 전환하고, 기존 토큰의 유효기간이 모두 지난 다음 예전 키를 제거합니다. JWKS로 공개키를 배포하면 kid 로 키를 구분할 수 있어 이 과정이 수월해집니다.

JWT를 암호화할 수도 있나요?

있습니다. 서명만 하는 JWS와 달리 JWE는 페이로드를 암호화합니다. 일반적으로 JWT라고 부르는 것은 JWS이며 페이로드는 Base64URL 인코딩일 뿐 누구나 읽을 수 있습니다. 따라서 개인정보나 권한의 상세 내용을 페이로드에 넣는 것은 공개하는 것과 같습니다. 감춰야 한다면 JWE를 쓰거나, 애초에 넣지 않는 편이 낫습니다.

같은 JWT를 인증과 인가에 모두 써도 되나요?

가능하지만 권장하지 않습니다. 인가 정보(권한·역할)는 자주 바뀌는 반면 JWT는 발급 후 회수할 수 없기 때문에, 권한을 낮췄는데도 기존 토큰으로는 여전히 접근되는 상황이 생깁니다. 권한은 요청 시점에 서버에서 확인하고, JWT에는 ‘누구인지’만 담는 설계가 안전합니다.

마치며

보안은 ‘불안’을 ‘확신’으로 바꾸는 과정입니다.
구조를 올바르게 알고 적절한 도구를 사용함으로써 여러분의 시스템은 더욱 강력해지고 신뢰받을 수 있습니다. 투박하지만 중요한 보안의 세계에 오신 것을 환영합니다.