JWT: 현대 웹 인증의 핵심

분산 시스템, 특히 마이크로서비스로 서비스 쪼개서 개발해보면 인증이 제일 먼저 발목 잡더라고요. 사용자 인증 정보를 여러 서비스에 안전하게, 그리고 효율적으로 공유해야 하는데 이게 생각보다 골칫거리입니다. 중앙 세션 저장소를 두자니 운영이 복잡해지고, 한 군데가 느려지면 전체가 같이 끌려가는 병목도 걱정되고요.

그때 동료가 툭 던진 게 JWT(JSON Web Token)였어요. 처음엔 “토큰이 뭐 대단하다고” 싶었는데, 막상 써보니 느낌이 딱 ‘신분증’이더군요. 서버가 사용자를 계속 기억하고 있을 필요 없이, 사용자가 신분증을 들고 오면 서비스는 유효한지만 확인하면 되는 방식이니까요. 이거 한 번 맛보면 왜 JWT가 여기저기서 기본 옵션처럼 붙는지 감이 옵니다.

JWT란 무엇이며, 핵심 개념은 뭔가요?

JWT를 제대로 쓰려면 “그냥 긴 문자열”로 보면 안 됩니다. JWT는 그 자체로 정보를 담고 있고, 디지털 서명으로 위조를 막는 구조를 갖고 있어요. 그래서 인증이나 정보 교환에 많이 쓰입니다. 여기서는 정의랑 구조를 먼저 잡고 갈게요.

what is a jwt token

JWT(JSON Web Token)는 IETF의 RFC 7519에 정의된 표준입니다. 간결하고 URL에 넣어도 비교적 안전한 형태라서, 두 당사자(예를 들면 브라우저와 서버) 사이에서 정보를 주고받는 용도로 설계됐습니다.

여기서 “간결하다”는 건 토큰이 상대적으로 작아서 HTTP 헤더나 URL에 실어 보내기 편하다는 뜻이고, “URL-안전하다”는 건 토큰을 구성하는 문자들이 URL에서 문제를 잘 안 일으키는 쪽으로 설계됐다는 의미예요.

JWT는 항상 마침표(.) 기준으로 3덩이로 나뉩니다. 각 덩이는 Base64URL로 인코딩되고요. 순서대로 헤더(Header), 페이로드(Payload), 서명(Signature)입니다.

JWT가 마이크로서비스 같은 분산 환경에서 특히 편한 이유가 두 가지 있어요. 하나는 무상태(stateless)고, 다른 하나는 자체 포함적(self-contained)이라는 점입니다.

무상태라는 건 서버가 “A 사용자가 로그인 중” 같은 상태를 메모리나 DB에 따로 들고 있지 않아도 된다는 뜻이에요. 예전 방식은 사용자 늘고 서버 늘어날수록 세션 동기화, 저장소 운영 같은 삽질이 같이 커지더라고요.

자체 포함적이라는 건 필요한 정보(사용자 식별자, 권한 같은 것들)를 토큰 안에 담아둔다는 의미고요. 감으로 비유하면 이렇습니다. 헤더는 “서명 알고리즘이 뭐예요” 같은 설명서, 페이로드는 “사용자 ID랑 권한이 뭐예요” 같은 내용물, 서명은 “이거 위조 아니에요”를 증명하는 봉인이요.

JWT 구성 요소 및 역할

jwt token

JWT 토큰은 보통 xxxxx.yyyyy.zzzzzCopy 형태로 보입니다. 각각 인코딩된 헤더, 페이로드, 서명을 뜻해요.

서명 알고리즘은 JWT 보안의 핵심입니다. 크게 대칭키(HMAC-SHA256 같은)와 비대칭키(RSA, ECDSA 같은)로 나뉘어요.

대칭키는 만들 때도 검증할 때도 같은 비밀 키를 씁니다. 집 열쇠 하나를 가족끼리 같이 쓰는 느낌이라 구조가 단순하고 빠른 편이에요. 반대로 비대칭키는 개인 키로 서명하고 공개 키로 검증합니다. 분산 환경에서 “여러 서비스가 각자 검증해야 하는” 상황이면 이 방식이 운영적으로도 안전한 경우가 많습니다. 개인 키는 인증 서버만 들고 있고, 나머지는 공개 키로만 검증하면 되니까요.

OWASP(Open Web Application Security Project)에서도 JWT 쓸 때 기본 수칙을 꽤 강조합니다.

1. 모든 JWT에는 만료 시간(exp 클레임)을 꼭 넣어야 합니다. 토큰이 탈취돼도 시간이 지나면 쓸모없게 만들어야 피해가 줄어요.
2. 토큰은 HTTPS로만 전송해야 합니다. 안 그러면 중간자 공격으로 토큰이 털릴 수 있어요.

페이로드에는 표준 클레임을 담을 수 있습니다. 예를 들면 iss(발급자), sub(주체, 보통 사용자 ID), aud(대상), exp(만료), iat(발급 시간) 같은 것들이요. 검증할 때 이 값들이 꽤 중요한 단서가 됩니다.

jwt 토큰

JWT 토큰은 사용자 인증, 권한 부여, 정보 교환에 널리 쓰이는 표준 토큰 형식입니다. Base64URL로 인코딩된 헤더/페이로드/서명 3파트로 구성되고, 마침표(.)로 구분됩니다. 언어나 플랫폼 가리지 않고 만들고 검증하기 쉬운 편이라 호환성도 좋아요.

MSA 환경에서 특히 좋은 점은 역시 무상태(stateless)입니다. 서버가 세션을 들고 있지 않아도 되니까 확장할 때 부담이 확 줄어들어요.

저도 MSA 프로젝트 하면서 서비스가 수십 개로 늘어나니까 인증 동기화가 진짜 귀찮아지더군요. 동료가 JWT 도입을 제안했고, 중앙 인증 서버가 토큰만 발급해주면 각 서비스가 독립적으로 검증하는 구조로 바꾸니까 개발 속도가 눈에 띄게 좋아졌습니다.

한국인터넷진흥원(KISA) 쪽 가이드에서도 비슷한 얘기를 합니다.
> 토큰이 네트워크로 오갈 때는 HTTPS 같은 보안 프로토콜을 쓰고, 만료 시간도 서비스 특성에 맞게 너무 길지 않게 잡아서 유출 시 악용 시간을 줄이라고 권고하더군요.
이런 건 “보안팀이 하라니까”가 아니라, 실제로 사고 한 번 나면 복구가 더 큰 삽질이라서요.

Practical Aspects of JWT: Decoding and Integration

구조를 이해했으면 이제 실전입니다. 이론은 알겠는데 코드로 들어가면 막막한 게 정상이에요. JWT를 디코딩해서 안에 뭐가 들었는지 확인하고, 라이브러리로 검증하고, Spring Security 같은 프레임워크에 붙이는 게 실제 업무 흐름이거든요. 여기서부터는 “어떻게 안전하게 다루냐” 쪽으로 보시면 됩니다.

jwt decode

JWT 디코딩(decode)은 Base64URL로 인코딩된 JWT를 사람이 읽을 수 있는 JSON 형태로 풀어보는 과정입니다. 그래서 헤더에서 알고리즘이 뭔지("alg": "HS256"), 페이로드에서 사용자 ID가 뭔지("sub": "12345") 같은 걸 눈으로 확인할 수 있어요.

여기서 제일 중요한 포인트가 하나 있습니다. 디코딩은 암호 해독(decryption)이 아니에요. Base64URL은 그냥 포장입니다. 엽서처럼 누구나 뜯어볼 수 있어요. 그래서 페이로드에 민감 정보 넣으면 큰일 납니다. 진짜로요.

그리고 디코딩만 해서는 토큰을 믿으면 안 됩니다. 반드시 서명 검증(signature verification)이 따라와야 해요. 서명 검증은 발급할 때 썼던 비밀 키(또는 공개 키)로 “이 토큰이 위조/변조되지 않았는지”를 확인하는 절차입니다.

서명 검증을 빼먹는 건, 제 기준엔 현관문 열어두고 외출하는 거랑 비슷합니다. 검증 없이 페이로드만 믿으면 공격자가 페이로드를 바꿔서(예: 일반 사용자를 관리자로) 위조 토큰을 보낼 수 있어요. 그래서 안전한 JWT 처리는 보통 서명 검증, 만료 시간 확인 같은 단계가 같이 들어갑니다.

jwt 디코딩

JWT 디코딩은 말 그대로 토큰을 풀어서 JSON을 확인하는 과정입니다. KISA 가이드라인에서도 서버가 JWT를 받으면 검증을 꼭 하라고 얘기해요. 보통 이런 걸 체크합니다. 서명 검증, exp 만료 확인, 그리고 iss나 aud 같은 클레임이 우리 서비스 기준에 맞는지 확인하는 것들이요.

저도 신입 때 삽질한 적이 있습니다. 클라이언트 자바스크립트에서 JWT 디코딩하고, 페이로드에 있는 권한 값(“role”: “admin”)을 그대로 믿고 관리자 메뉴를 보여주는 코드를 짰다가 선임한테 제대로 혼났어요. 개발자 도구로 값 바꾸는 건 너무 쉽거든요.

중요한 권한 체크는 무조건 서버에서, 토큰을 안전하게 검증한 다음에 하셔야 합니다. 클라이언트는 서버가 내려준 결과를 믿는 쪽으로 가는 게 안전해요.

jwt decoder

JWT 디코더(decoder)는 토큰을 파싱하고 디코딩하고, 서명 검증까지 도와주는 도구나 라이브러리를 말합니다. 요즘은 언어별로 괜찮은 라이브러리가 다 있어요. 이런 건 직접 구현하려고 덤비면 보통 삽질로 끝납니다. 암호/서명 쪽은 사소한 실수가 바로 보안 구멍이 되거든요.

주요 프로그래밍 언어별 JWT 라이브러리 예시

라이브러리 고를 때는 이런 걸 봐두면 좋습니다. HS256, RS256 같은 알고리즘 지원 여부, 표준 클레임 자동 검증 옵션, 그리고 업데이트가 꾸준한지요. 개인적으로 Java에서는 jjwt를 자주 쓰는데, API가 직관적이고 문서도 괜찮아서 처음 붙일 때 덜 헤매더라고요.

jwt parser

JWT 파서(parser)는 토큰 문자열을 구조적으로 쪼개서 헤더/페이로드/서명을 분리하고, 필요한 경우 Base64URL 디코딩까지 해주는 쪽에 더 가까워요. 기본적으로는 “이 문자열이 JWT 형태(xxxxx.yyyyy.zzzzzCopy)가 맞냐”부터 확인합니다. 우체부가 주소부터 보는 것처럼요.

> SANS Institute 쪽에서도 JWT 파서 쓸 때 입력값 검증을 철저히 하라고 권장합니다. 비정상적으로 길거나 조작된 토큰을 제대로 처리 못 하면 장애나 보안 문제가 생길 수 있거든요.
그래서 이런 로직을 직접 다 만들기보다는, 검증된 라이브러리를 쓰는 게 보통 더 안전합니다.

jwt io

JWT.io는 Auth0에서 운영하는 JWT 디버깅 사이트로 많이 알려져 있습니다. 왼쪽에 JWT를 붙여넣으면 오른쪽에 디코딩된 헤더/페이로드를 JSON으로 보여줘서 학습이나 테스트에 꽤 유용해요.

저도 “왜 서명 검증이 실패하지?” 같은 상황에서 jwt.io로 빠르게 확인하곤 했습니다. 토큰이랑 키를 넣어보면 어디가 문제인지 감이 오거든요.

다만 이건 진짜 조심하셔야 합니다. 실서비스(프로덕션) 토큰은 절대 붙여넣지 마세요. 민감한 정보가 외부로 나갈 수 있고, 그 한 번이 사고로 이어질 수 있습니다. 개발/테스트용 샘플 토큰만 쓰는 걸로요.

spring security jwt

Spring Security에서 JWT 기반 인증/인가를 붙이는 걸 보통 “Spring Security JWT”라고들 부릅니다. Spring Security에 JWT를 잘 얹으면 무상태 인증을 비교적 깔끔하게 구성할 수 있어요. 특히 Spring Security 5.x 이후로는 설정이 많이 편해졌습니다.

예를 들어 공개 키 위치(JWK Set URI)만 application.propertiesCopy 같은 설정에 잡아주면, Spring Security가 서명 검증과 인증 처리를 꽤 많이 자동으로 해줍니다.

Spring Security JWT 쓸 때 같이 챙기면 좋은 보안 설정도 있어요.

1. CORS 정책을 서비스 상황에 맞게 설정합니다. 프론트와 백이 주소가 다르면 특히요.
2. CSRF 방어 설정은 “우리 구조에서 필요한지”를 기준으로 신중하게 봐야 합니다.

Spring Security는 JwtDecoder, JwtEncoder 같은 도구도 제공해서 토큰 생성/검증을 커스터마이징할 수 있습니다. 제 경험상, 자동 설정으로 최대한 가고 꼭 필요한 부분만 손대는 게 생산성도 좋고 사고도 덜 나더라고요.

JWT는 마이크로서비스나 현대 웹에서 인증/정보 교환을 꽤 유연하게 만들어주는 도구입니다. 다만 “토큰 썼으니 끝”이 아니라, 서명 검증, 만료 시간, HTTPS 전송 같은 기본 수칙을 지키는 게 진짜 핵심이에요. 여기만 대충하면 JWT는 편한 신분증이 아니라, 그냥 잘 포장된 폭탄이 됩니다.

처음 붙일 때는 당연히 헤맬 수밖에 없어요. 저도 그랬고요. 한 번에 완벽하게 하려고 하기보다, 작은 샘플부터 붙여보고 로그 찍어가면서 검증 흐름을 손에 익히는 게 제일 빠릅니다. 막히는 포인트 있으면 그 지점만 딱 집어서 다시 같이 보셔도 됩니다.

FAQ

Q1: JWT의 세 가지 구성 요소는 무엇이며 각각 어떤 역할을 하나요?
A1: JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성됩니다. 헤더는 서명 알고리즘 같은 메타 정보를 담고, 페이로드는 사용자 ID나 권한 같은 실제 데이터를 담습니다. 서명은 토큰이 위조/변조되지 않았다는 걸 검증할 수 있게 해주는 값입니다.

Q2: JWT 페이로드에 담긴 정보는 암호화되어 안전한가요?
A2: 아니요. 페이로드는 암호화가 아니라 Base64URL 인코딩이라서 디코딩하면 누구나 볼 수 있습니다. 비밀번호나 주민번호 같은 민감 정보는 절대 넣으면 안 돼요.

Q3: JWT 토큰을 받은 후 가장 먼저 해야 할 보안 절차는 무엇인가요?
A3: 서명 검증입니다. 디코딩은 내용을 보는 거고, 서명 검증은 “이 토큰이 진짜냐”를 확인하는 절차예요. 검증 통과 전에는 페이로드를 믿으면 안 됩니다.

Q4: JWT가 ‘무상태(stateless)’라고 불리는 이유는 무엇인가요?
A4: 서버가 로그인 상태를 따로 저장하고 기억할 필요가 없기 때문입니다. 요청이 올 때마다 토큰 유효성만 확인하면 되니 확장하기가 훨씬 편해져요.

Q5: JWT.io와 같은 온라인 디버깅 도구를 실제 서비스 토큰에 사용해도 되나요?
A5: 안 됩니다. 학습/개발용 샘플 토큰만 넣으세요. 프로덕션 토큰을 온라인 도구에 붙여넣는 건 정보 유출로 이어질 수 있습니다.