JWT(JSON Web Token) 구조와 디코딩 이해

로그인 상태를 유지하거나 API 요청에 사용자를 식별할 때 자주 등장하는 것이 JWT(JSON Web Token)입니다. 점(.)으로 이어진 긴 문자열이 무슨 의미인지 궁금했다면, 구조만 알면 의외로 단순합니다. JWT의 세 부분이 각각 무엇을 담는지, 디코딩과 서명 검증이 어떻게 다른지 정리하고 JWT 디코더로 직접 내용을 확인하는 방법을 알아봅니다.

한눈에 보기

• JWT는 헤더.페이로드.서명 세 부분을 점(.)으로 연결한 문자열입니다.
• 각 부분은 Base64URL로 인코딩되어 있습니다.
• 헤더는 알고리즘과 타입, 페이로드는 클레임(데이터), 서명은 위변조 검증용입니다.
• 디코딩(내용 확인)은 누구나 가능하지만, 이는 서명 검증과는 다릅니다.
• 페이로드는 누구나 읽을 수 있으므로 비밀번호 등 민감정보를 넣지 말아야 합니다.

JWT의 세 부분

JWT는 정확히 두 개의 점으로 나뉜 세 조각으로 구성됩니다. 예를 들어 eyJhbGc... . eyJzdWI... . SflKxw... 형태입니다. 각 조각은 Base64URL로 인코딩되어 있어, 디코딩하면 사람이 읽을 수 있는 내용이 나옵니다.

가장 먼저 오는 헤더에는 어떤 알고리즘으로 서명했는지(alg)와 타입(typ) 정보가 들어갑니다. 두 번째 페이로드에는 실제 전달하려는 데이터가, 마지막 서명에는 토큰이 변조되지 않았음을 증명하는 값이 담깁니다.

페이로드의 클레임(claim)

페이로드에는 토큰이 표현하는 정보가 키-값 형태로 들어가는데, 이를 클레임이라 부릅니다. 자주 쓰이는 표준 클레임은 다음과 같습니다.

• sub — 주체(subject), 보통 사용자 식별자
• exp — 만료 시각(expiration). 이 시간이 지나면 토큰은 더 이상 유효하지 않습니다.
• iat — 발급 시각(issued at)

exp 값으로 토큰의 수명을 관리하므로, 서버는 만료된 토큰을 거부할 수 있습니다. 어떤 클레임이 들어 있는지 궁금하다면 JWT 디코더에 토큰을 붙여 넣어 페이로드를 바로 확인할 수 있습니다.

디코딩과 서명 검증은 다르다

가장 흔한 오해가 "디코딩되니까 안전하지 않다"거나 반대로 "서명이 있으니 내용이 숨겨진다"는 생각입니다. 둘 다 사실이 아닙니다.

• 디코딩: Base64URL을 풀어 헤더와 페이로드의 내용을 읽는 것. 키나 비밀이 필요 없어 누구나 가능합니다.
• 서명 검증: 토큰이 발급 이후 변조되지 않았는지 비밀 키로 확인하는 것. 이것이 JWT의 보안 핵심입니다.

즉, 페이로드는 잠겨 있는 것이 아니라 단지 인코딩되어 있을 뿐입니다. 서명은 내용을 숨기지 않고, "이 내용이 바뀌지 않았다"는 사실만 보장합니다. 그래서 페이로드에 비밀번호나 주민등록번호 같은 민감정보를 넣어서는 안 됩니다.

자주 묻는 질문

JWT 페이로드는 암호화되어 있나요?

아닙니다. Base64URL로 인코딩되어 있을 뿐이라 JWT 디코더로 누구나 내용을 읽을 수 있습니다. 비밀로 유지해야 할 정보는 담지 마세요.

그럼 서명은 무슨 역할을 하나요?

토큰이 발급된 뒤 내용이 변조되지 않았는지 확인합니다. 누군가 페이로드를 바꾸면 서명 검증이 실패하므로 서버가 위조를 잡아낼 수 있습니다.

exp는 어떻게 활용하나요?

만료 시각을 담은 클레임입니다. 서버는 현재 시각과 exp를 비교해 만료된 토큰을 거부함으로써 토큰의 수명을 관리합니다.

점(.)이 두 개인 이유는?

헤더·페이로드·서명 세 부분을 구분하기 위해 점으로 연결하기 때문입니다. 따라서 점은 항상 두 개입니다.

마무리

JWT는 헤더.페이로드.서명 구조를 가진 Base64URL 문자열이며, 디코딩으로 내용을 확인하는 것과 서명으로 위변조를 검증하는 것은 전혀 다른 일입니다. 페이로드는 누구나 읽을 수 있다는 점만 기억하면 민감정보 노출 실수를 막을 수 있습니다. 토큰 내용이 궁금할 때는 JWT 디코더에서 바로 헤더와 페이로드를 열어 확인해 보세요.