JWT 란 무엇인가?

2010년 IETF 초안으로 시작된 JWT는 ‘JSON + Base64url + SHA-256’ 조합으로 경량·가독성·모바일 친화 포맷을 목표로 했다. 2015년 RFC 7519로 표준화되며 OAuth 2.0·OpenID Connect 토큰의 사실상 기본 표현식이 됐다. (How OpenID Connect Works - OpenID Foundation, RFC 7515 - JSON Web Signature (JWS) - IETF Datatracker)

SAML의 시대적 한계

2000 년대 초·중반 엔터프라이즈 SOA 환경은 대개 SOAP/WS-* 스택 위에서 돌아갔습니다.

SAML 1.1/2.0은 이 생태계에 맞춰 설계돼, 인증 정보를 XML 문서(Assertion) 안에 담고, XML-DSig·X.509 인증서로 서명·검증했습니다.
당시엔 브라우저↔기업 포털 간 SSO가 주된 요구사항이었고, 인터넷 회선도 데스크톱-LAN 중심이라 수 KB짜리 XML이 크게 문제 되지 않았습니다.

하지만 2009~2012 년 사이 환경이 급변합니다.

스마트폰(3G)·태블릿·SPA(AngularJS, Backbone 등) 붐 → 저대역폭에서 빠른 JSON/REST API 필요
마이크로서비스·클라우드 확산 → 서비스 수십~수백 개로 분할, 토큰을 자주 주고받음
개발 생산성·보안
- XML-DSig은 태그 위치 하나만 바뀌어도 서명 검증이 깨지는 등 버그 내재 가능성이 컸고, 구현 난도가 높아 취약점을 흔히 야기했습니다. (SAML vs OIDC: All You Need to Know - OneLogin)
- IdP-SP 간 메타데이터·인증서 교체가 번거로워 키 롤링도 어렵고 다운타임 위험이 컸습니다.

결국 “가볍고(Compact)·단순하고(JSON)·모바일 친화적이며 무상태(Stateless)”인 대체 포맷이 필요했고, 이 요구가 JWT·OAuth 2.0·OpenID Connect 같은 JSON·HTTP 기반 프로토콜을 폭발적으로 확산시켰습니다. (Why You Wouldn't Use SAML in a SPA and Mobile App, SAML token size and REST - Stack Overflow)

요약 : XML 중심 ‘WS-* 시대’에서 만들어진 SAML은 모바일·SPA·마이크로서비스 세상에선 “너무 크고, 너무 복잡하고, 너무 느렸다.” 그래서 현대 웹은 SAML을 계속 지원하되, JWT를 기본 토큰으로 사용하는 방향으로 이동하게 되었습니다.

SAML을 대체해야 했던 이유

복잡성 : XML-DSig·SOAP 바인딩, 다수의 메타데이터 파일 관리가 어렵다. (OIDC vs. SAML: Understanding the Differences and Upgrading to ...)
확장성 부족 : 서버 세션·쿠키 중심이라 모바일 앱/마이크로서비스에서 번거로운 우회(웹뷰 로그인 등)가 필요. (The 3 best alternatives to SAML SSO - WorkOS)
대용량 메시지 : 네트워크·HTTP 헤더 부담.
증명서 갱신 번거로움 : 양쪽( IdP ↔ SP )이 동시에 교체해야 중단이 없다.

JWT가 각광받은 이유

Stateless 스케일링 : 토큰 자체에 상태 포함 → 세션 공유·Sticky Session 불필요. 마이크로서비스·서버리스 환경과 궁합이 좋다. (Authentication Series #EP2: How JWT Revolutionized Stateless ..., The Purpose of JWT: Stateless Authentication)
다양한 클라이언트 : 모바일·SPA·IoT에서도 쿠키 제약 없이 Authorization: Bearer 헤더로 동일하게 사용. (Token based Authentication in Spring Boot Applications - Medium)
표준 확장체계(JOSE) : JWS·JWE 등으로 서명·암호화 방식을 모듈화해 보안 선택지가 넓다.
광범위한 생태계 : AWS Cognito, Firebase, Auth0, Keycloak 등 클라우드 서비스가 기본 지원 → 도입 장벽↓

JWT 구조

JWT는 점(.)으로 구분된 세 개의 Base64url 문자열로 구성됩니다.

예시는 RS256(비대칭) 서명을 사용하는 Access Token을 가정한 것입니다.

Header (JSON)

{
  "alg": "RS256",          // 서명 알고리즘
  "typ": "JWT",            // 토큰 타입
  "kid": "1234abc"         // 키 식별자(선택)
}

alg : 서명 또는 암호화 알고리즘(예 HS256, RS256)
typ : 보통 “JWT”로 고정하며, 토큰 유형을 나타냅니다.
kid (선택) : 다수의 키를 운용할 때 특정 키를 식별하기 위한 값입니다.

Payload (JSON)

페이로드(Payload) : 실제로 전달하려는 클레임(Claim) 을 담는 JSON 객체입니다.

{
  "iss": "https://auth.example.com",     // 발급자(Issuer)
  "sub": "user123",                      // 주체(Subject = 사용자 ID)
  "aud": "https://api.example.com",      // 대상 Audience
  "iat": 1714272000,                     // 발급 시각(Unix time)
  "exp": 1714275600,                     // 만료 시각
  "scope": "read:posts write:posts",     // 권한 범위(커스텀 클레임)
  "role": "admin"                        // 애플리케이션 전용 클레임
}

등록(Registered) 클레임 : 규격에 예약된 필드(iss 발급자, sub 주체, aud 대상, exp 만료, iat 발급시각 등).
공개(Public) 클레임 : URI 등으로 네임스페이스를 명확히 한, 여러 시스템이 공유할 수 있는 필드.
비공개(Private) 클레임 : 서비스 고유 데이터(role, scope 같이 애플리케이션에 특화된 정보).

Signature 생성

시그니처(Signature) : 헤더.페이로드 문자열을 비밀키(대칭) 또는 개인키(비대칭)로 서명한 값입니다. 이 부분 덕분에 토큰이 위·변조되지 않았음을 검증할 수 있습니다.

signature = RSASHA256(
              Base64url(header) + "." + Base64url(payload),
              private_key
            )

Base64url 인코딩 & 조합

Base64url(header)  = eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMzRhYmMifQ
Base64url(payload) = eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1...

최종 JWT

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMzRhYmMifQ
.
eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyMTIzIiw...
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

<헤더>. <페이로드>. <시그니처> 형태의 단일 문자열로 브라우저·모바일·서버 사이를 가볍게 이동합니다. 원하는 경우 헤더의 alg를 “dir”·“RSA-OAEP” 등으로 지정해 JWE(JSON Web Encryption) 방식으로 암호화된 토큰을 만들 수도 있습니다. 이렇게 구조를 단순화한 덕분에 토큰 자체만으로 무상태(Stateless) 인증·권한 확인이 가능해졌고, 마이크로서비스와 클라우드 환경에서 널리 채택되었습니다.

(줄바꿈은 가독성을 위한 것이며 실제 전송 시에는 한 줄로 붙어 있습니다.)

작동 흐름

단계	클라이언트	인증 서버(IdP)	API/자원 서버
① 로그인	아이디·비밀번호 제출	자격 확인 후 Header+Payload 작성 → 개인키로 서명 → JWT 발급
② 토큰 저장	로컬 스토리지·Cookie·메모리 등 선택 위치에 JWT 보관
③ 요청	`Authorization: Bearer <JWT>` 포함해 /posts 엔드포인트 호출		공개키로 서명 검증 → `exp`, `scope` 체크권한 OK면 데이터 응답
④ 만료	`exp` 초과 시 Refresh Token(또는 재로그인)로 새 JWT 요청	기존 토큰 폐기, 새 JWT 발급

✔️ 무상태(Stateless) 특성 덕분에 API 서버는 중앙 세션 저장소 없이도, 공개키만 있으면 토큰을 즉시 검증할 수 있습니다. 이 점이 모바일·마이크로서비스·서버리스 환경에서 JWT가 각광받은 가장 큰 이유 중 하나입니다.

JWT 는 어떤 기술·표준에서 파생되었나?

선행 기술	핵심 개념	JWT에 준 영향
JSON (RFC 7159)	경량 데이터 표현, 브라우저·모바일 친화	토큰 본문을 XML 대신 JSON으로 설계하기로 함
Base64url (RFC 4648 §5)	URL-Safe 인코딩(+, /, = 제거)	헤더·페이로드를 `.` 로 연결해 한 줄 문자열로 만들 수 있게 함
Simple Web Token (SWT)	2009 년 MS 주도 “HMAC-SHA256 서명 JSON 쿼리 스트링” 토큰	“작고 서명만 있으면 충분” 이라는 아이디어를 확장 ➜ JW* 시리즈로 발전 (SWT vs JWT - Light-4j, Anatomy of a Simple Web Token (SWT))
OAuth 2.0 Bearer Token (draft 2011)	리소스 서버가 “Authorization: Bearer ” 만으로 권한 체크	JWT를 Bearer 토큰 포맷으로 공식 프로파일링(2012 Internet-Draft) (JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0, draft-jones-oauth-jwt-bearer-00.txt)
SAML 2.0 Assertion	XML + X.509 서명으로 신원·권한 기술	“클레임을 토큰 내부에 싣는다” 발상 계승. 단점(무겁고 복잡)을 개선하기 위해 JSON 버전이 필요 (JSON Web Token Introduction - jwt.io)

다시 말해 JWT는 “JSON + Base64url + SWT의 경량 서명 방식”에 “OAuth Bearer Token”의 전송 관례를 결합해 탄생한, 2010년대형 토큰 포맷입니다. JOSE 스택(JWS·JWE·JWA)은 이 아이디어를 확장해 서명·암호화 알고리즘을 모듈화하면서 동시에 표준화되었습니다. (draft-ietf-oauth-jwt-bearer-11)

JWT 주요 용도 & 선택된 이유

용도	JWT가 선택된 핵심 이유
사용자 인증	세션을 들고 다니지 않아 SPA·모바일에서 Roaming 로그인 용이.
OAuth 2.0 Access Token	리소스 서버가 중앙 인증 스토어 없이 토큰만으로 권한 확인.
OpenID Connect ID Token	표준 클레임(이메일, 이름 등)을 자체 포함해 사용자 프로필 API 호출 감소.
마이크로서비스 간 클레임 전달	토큰만 전달하면 각 서비스가 독립적으로 권한 체크 가능 → 서비스 수평 확장 간단.
SSO(기업·교육기관)	SAML 대비 1/10 수준 크기·JSON 가독성·모바일 친화성.

JWT vs 다른 인증 시스템 한눈 비교

항목	세션 쿠키	SAML 2.0	JWT(JWS/JWE)
상태	서버 저장	서버/IdP 세션	무상태
포맷	임의 문자열	XML + 서명	JSON + 서명/암호화
용량	짧음	큼(수 KB)	중간(수 백 B)
모바일·API	쿠키 제한	Webview 우회	헤더 전송 손쉬움
실시간 무효화	서버 삭제 쉬움	IdP와 SP 동시 처리	Blacklist 필요
키 갱신	세션 영향 없음	인증서 교체 복잡	`kid`로 무중단 회전 가능

마무리

JWT는 “작고, 스스로를 증명하며, 서버에 짐을 지우지 않는 토큰” 입니다.

SAML의 복잡함을 넘어 모바일·클라우드 시대가 요구한 경량·무상태·확장성을 충족해 급부상했지만,

만료 관리,
민감 정보 노출 방지,
토큰 크기 관리는 여전히 설계자가 책임져야 합니다.

적절한 만료 주기, Refresh Token·블랙리스트, JWE 사용 등을 함께 고려해 안전하고 유연한 인증 시스템을 구축하세요!

김규민

To Infinity, and Beyond!

다음 포스트

JWT 란 무엇인가?

개발공부

JWT 공식 사이트 및 참고 사이트

JWT 가 무엇인지 알아보도록 하자

JWT 공식 정의

비유적으로 표현하자면

JWT 탄생 배경