JWT 보안 고려사항
JWT 보안 고려사항 (Security Considerations)
JWT(RFC 7519)의 부록에는 토큰을 안전하게 사용하기 위한 보안 고려사항이 정리돼 있어요. JWT는 자체 포함(self-contained) 토큰이라서 서버에 세션을 저장할 필요가 없지만, 그 대신 검증 실패 시 발생하는 위험이 있어요. 이 절은 그러한 위험과 대비책을 다뤄요.
JWT를 다룰 때 가장 중요한 원칙은 항상 서명(또는 MAC)을 먼저 검증하고, 그다음 클레임을 신뢰하는 것이에요.
출처: https://datatracker.ietf.org/doc/html/rfc7519#section-10
신뢰 경계
JWT를 발행한 쪽과 검증하는 쪽이 서로 다른 주체라면, 수신자는 공개 키가 검증된 출처(예: 신뢰된 JWKS 엔드포인트)에서 왔는지 확인해야 해요. 서명 검증에 실패한 토큰은 절대 신뢰해서는 안 돼요. 스펙은 "서명을 검증하지 않으면 JWT를 신뢰하지 말 것"을 강조해요.
클레임 검증
보안에 민감한 애플리케이션에서는 아래 클레임들을 반드시 확인해요.
iss(issuer) — 토큰 발행자가 예상하는 주체와 일치하는지sub(subject) — 토큰의 주체aud(audience) — 수신자가 의도된 수신자(aud)와 일치하는지exp(expiration time) — 현재 시간이 만료 시간을 넘지 않았는지nbf(not before) — 아직 유효 시작 전이 아닌지iat(issued at) — 발행 시각이 너무 미래거나 크게 벗어나지 않는지jti(JWT ID) — 재생(replay) 방지를 위한 고유 식별자
aud 검증을 소홀히 하면 서로 다른 서비스 간에 토큰이 재사용될 수 있어요. exp를 확인하지 않으면 만료된 토큰이 계속 유효하게 쓰일 수 있어요.
알고리즘 혼동 공격
JWT에서 유명한 공격 기법이 **알고리즘 혼동(algorithm confusion)**이에요. 공격자가 서버가 비대칭 서명(RS256)을 기대하는데 토큰의 alg를 대칭(HS256)으로 바꿔서 서버의 공개키를 비밀 키로 사용해 서명해 버리는 식이에요. 이를 막으려면:
alg를 서버가 허용한 수신 목록(화이트리스트)과 대조해요.- 예상 밖의 알고리즘(
none포함)은 거부해요. - 검증 시 키 유형(
kty)과 알고리즘을 함께 확인해요.
키 관리
- 키는 안전하게 보관하고, 유출 시 즉시 교체(rotation)해요.
- 서명 키와 암호화 키를 분리해 쓰는 게 좋아요.
kid기반 키 선택 시, 신뢰된 키 목록에 없는kid는 거부해요.
기타
- 토큰을 로그·URL에 그대로 남기지 않도록 주의해요.(특히 JWE로 암호화하지 않은 JWS)
- 하드코딩된 키, 약한 대칭 키 길이를 피해요.
- 재생 공격 방지가 필요하면
jti와 만료 기간을 짧게 잡아요.