‘어쩌다 보니’ 쓰고 있지는 않나요?
현대적인 웹 개발에서 인증의 주역이 된 JWT (JSON Web Token). 워낙 라이브러리들이 훌륭하다 보니 내부 구조를 자세히 몰라도 일단 작동하는 프로그램을 만들 수는 있습니다. 하지만 그러한 ‘어쩌다 보니’ 식의 사용이 때로는 돌이킬 수 없는 보안 구멍을 만들기도 합니다.
“JWT는 결국 무엇을 보호하는 걸까?”, “서명과 해싱은 무엇이 다를까?”
이런 궁금증들을 해소하고, 자신 있게 보안을 이야기할 수 있는 엔지니어가 되어 봅시다.
JWT를 구성하는 ‘3개 파편’의 역할
JWT는 점(.)으로 구분된 세 부분으로 구성됩니다.
- Header: ‘어떤 방식으로 서명했는가’를 적어둔 봉투의 겉면.
- Payload: ‘누가’, ‘언제까지’ 유효한가를 적어둔 편지 내용.
- Signature: 봉투가 중간에 열리거나 내용이 바뀌지 않았음을 증명하는 ‘검인’.
여기서 가장 중요한 점은 **‘헤더와 페이로드는 누구나 읽을 수 있다’**는 것입니다. Base64로 인코딩되어 있을 뿐 암호화된 것이 아니기 때문입니다. 페이로드에 비밀번호나 카드 번호를 넣는 것은 편지 내용을 투명한 비닐봉지에 담아 보내는 것과 같습니다.
신뢰의 핵심: 서명과 해싱
JWT의 진정한 가치는 그 ‘무결성’에 있습니다. 그리고 이를 지탱하는 것이 바로 해싱과 서명입니다.
- 해싱(Hashing): 데이터의 ‘디지털 지문’을 만드는 작업입니다. (예: “이 데이터라면 반드시 이 값이 나온다”)
- 서명(Signing): 해시값에 비밀 키로 도장을 찍는 것입니다. 키가 없는 제3자가 페이로드의 글자 하나라도 바꾸면 서명과의 일관성이 깨지고, 즉시 ‘위조품’임이 드러나게 됩니다.
키를 어떻게 배포할 것인가: JWKS의 마법
RSA와 같은 공개키 방식의 인증을 사용할 때, 검증하는 쪽은 어떻게 키를 얻어야 할까요?
이때 사용되는 것이 바로 **JWKS (JSON Web Key Set)**입니다.
서버가 “최신 공개키는 이거야!”라고 웹상에 공개하고, 검증하는 쪽이 이를 자동으로 읽어가는 방식입니다. 이를 통해 시스템 중단 없이 안전하게 키를 주기적으로 업데이트(로테이션)할 수 있습니다.
DevToolKits로 보안을 ‘체감’하기
글로만 이해하기 어려운 개념도 직접 움직여 보면 금방 이해할 수 있습니다.
- JWT 도구: 내 토큰이 어떤 ‘파편’으로 이루어져 있는지 브라우저 상에서 안전하게 들여다보세요.
- JWKS 생성기: 키 쌍을 생성하고 실제 어떤 JSON 형식으로 공개되는지 시뮬레이션해 보세요.
- 해시 생성 도구: SHA-256 등을 사용하여 데이터가 어떻게 ‘지문’으로 변하는지 직접 확인해 보세요.
마치며
보안은 ‘불안’을 ‘확신’으로 바꾸는 과정입니다.
구조를 올바르게 알고 적절한 도구를 사용함으로써 여러분의 시스템은 더욱 강력해지고 신뢰받을 수 있습니다. 투박하지만 중요한 보안의 세계에 오신 것을 환영합니다.