JWT 라이브러리가 서명을 검증했습니다. 토큰의 alg·kid·issuer를 그대로 따라도 되나요?

검증할 알고리즘과 신뢰 키·발급자·대상은 서버 정책에서 정해야 합니다. 토큰 헤더가 제시한 알고리즘이나 키 주소를 무조건 따라가면 신뢰 경계를 공격자가 선택하게 됩니다.

동작 원리와 전제

허용 알고리즘을 고정하고 issuer·audience·만료·시간 조건을 검사합니다. kid는 신뢰한 키 집합에서 선택하는 힌트이지 임의 파일 경로나 URL이 아닙니다. 인증용 토큰과 다른 용도의 JWT를 같은 검증기로 받아들이는 혼동도 막습니다.

선택과 실패 처리

키 회전 시 새 키·옛 키 검증 창을 관리하고 JWKS 캐시·재조회 횟수를 제한합니다. 모르는 kid마다 무제한 외부 조회하면 부하를 유발할 수 있습니다. 키를 바꿨다고 이미 발급한 토큰이 즉시 무효화되는지도 별도 정책입니다.

구체적인 사례와 검증

토큰의 kid가 신뢰한 JWKS 안의 키를 고르는 용도라면 모르는 값은 제한된 재조회 후 거절해야 합니다. 임의 URL을 가져오거나 로컬 파일명을 구성하는 입력으로 사용하지 않습니다. 같은 서명 키를 여러 목적의 토큰에 공유하면 issuer·audience·type·필수 claim 검사를 더 명확히 해야 다른 문맥의 토큰이 섞이지 않습니다. exp가 있어도 이미 회수한 계정의 접근을 즉시 막으려면 별도 세션·버전 상태가 필요합니다. 테스트는 단순 변조 서명 외에 유효한 다른 목적 토큰을 잘못 받아들이는 경우도 포함해야 검증기의 문맥 경계를 확인할 수 있습니다.

다른 발급자·잘못된 audience·알고리즘·kid·만료와 회전을 시험합니다. 서명 유효성은 내용이 그 키로 발급됐다는 증거이지 자원 접근 승인 자체가 아닙니다. 사용자 상태·세션 회수·행 소유권은 서버 인가에서 계속 검사합니다.