JWT(JSON Web Token)

JWT(JSON Web Token)는 당사자 간에 정보를 JSON 객체 형태로 안전하게 전송하기 위한 개방형 표준(RFC 7519)입니다. 주로 웹이나 모바일 애플리케이션에서 '인증(Authentication)'과 '권한 부여(Authorization)'를 처리하는 데 사용됩니다.

---

1. 쉽게 이해하는 비유: 놀이공원 자유이용권 (Wristband)

놀이공원 매표소에서 신분증과 결제 수단을 확인(로그인)하면, 팔목에 '자유이용권 팔찌(JWT)'를 채워줍니다. 이후에는 놀이기구(서버의 자원)를 탈 때마다 매표소에 갈 필요 없이, 팔찌만 보여주면 직원이 팔찌의 유효성(위변조 여부, 날짜)만 확인하고 바로 탑승을 허락합니다.

---

2. JWT의 3단 구조

JWT는 .(점)을 구분자로 하여 세 가지 파트로 나뉘며, xxxxx.yyyyy.zzzzz 형태의 긴 문자열로 구성됩니다.

 

• Header (헤더): 토큰의 타입(JWT)과 서명에 사용된 암호화 알고리즘(예: HMAC SHA256, RSA) 정보를 담고 있습니다.

 

• Payload (페이로드): 실제로 전달하려는 데이터가 들어있습니다. 이 데이터의 조각들을 클레임(Claim)이라고 부르며, 사용자 ID, 권한 등급, 토큰 만료 시간(exp) 등이 포함됩니다.
  • 주의사항: 페이로드는 암호화되지 않고 단순 인코딩(Base64)만 되므로, 비밀번호 같은 민감한 정보는 절대 넣으면 안 됩니다.

 

 

 

 

• Signature (서명): 헤더와 페이로드를 합친 후, 서버만 알고 있는 '비밀키(Secret Key)'를 사용해 암호화한 결과물입니다. 이 서명을 통해 토큰이 중간에 위조되거나 변조되지 않았음을 검증합니다.

---

3. 동작 원리 (Step-by-Step)

1. 로그인 요청: 클라이언트(사용자)가 아이디와 비밀번호를 서버에 보냅니다.

2. 토큰 발급: 서버는 회원 정보를 확인한 후, 사용자 고유 정보와 유효 기간 등을 담아 JWT를 생성하고 클라이언트에게 전달합니다.

 

3. 토큰 저장 및 요청: 클라이언트는 전달받은 JWT를 로컬(예: Local Storage, Cookie)에 저장하고, 이후 서버에 자원을 요청할 때마다 HTTP 헤더(Authorization: Bearer <token>)에 JWT를 실어서 보냅니다.

 

4. 토큰 검증 및 응답: 서버는 데이터베이스를 매번 조회할 필요 없이, 자신이 가진 비밀키로 JWT의 '서명(Signature)'만 검증합니다. 유효성이 확인되면 요청한 데이터를 반환합니다.

---

4. JWT의 장단점 비교

구분	특징 및 상세 설명
장점 (Pros)	서버 무상태성(Stateless): 서버가 사용자 세션 상태를 유지하거나 세션용 DB를 조회할 필요가 없어 확장성(Scalability)이 뛰어납니다. 다양한 환경 지원: 모바일 앱, MSA(마이크로서비스 아키텍처) 등 분산 환경에서 인증을 공유하기 좋습니다.
단점 (Cons)	정보 탈취 위험: 토큰 자체에 권한 정보가 담겨 있어 탈취당하면 만료될 때까지 막기 어렵습니다. 토큰 무효화 불가: 한 번 발급된 토큰은 유효기간이 끝날 때까지 서버에서 강제로 만료시키거나 취소하기 까다롭습니다. 트래픽 오버헤드: 담는 데이터(클레임)가 많아질수록 토큰 길이가 길어져 네트워크 대역폭을 낭비할 수 있습니다.

---

OAuth와 JWT는 자주 결합하여 사용됩니다. OAuth가 '권한을 위임받는 전반적인 과정과 규칙(프로토콜)'이라면, JWT는 그 과정의 결과물로 발급되는 '증명서의 한 종류(토큰 포맷)'라고 볼 수 있습니다.