JWT

작성자

익명

작성일

2026.02.01

조회수

버전

JWT

개요

JWT(JavaScript Object Notation Web Token)는 네트워크 상에서 정보를 JSON 객체 형태로 안전하게 전달하기 위한 개방형 표준(RFC 7519)입니다. 주로 사용자 인증 및 정보 교환에 활용되며, 서버와 클라이언트 간의 상태 비저장(stateless) 인증을 구현하는 데 널리 사용됩니다. JWT는 자체적으로 정보를 포함하므로, 수신 측에서 추가적인 데이터베이스 조회 없이도 토큰의 유효성과 사용자 정보를 확인할 수 있습니다.

JWT는 세 부분으로 구성되며, 각 부분은 점(.)으로 구분됩니다: 헤더(Header), 페이로드(Payload), 서명(Signature). 이 구조 덕분에 토큰이 위조되지 않았는지 검증할 수 있으며, 신뢰할 수 있는 주체에 의해 발급되었음을 보장합니다.

구조

JWT는 다음과 같은 세 가지 구성 요소로 이루어져 있습니다:

xxxxx.yyyyy.zzzzz

1. 헤더 (Header)

헤더는 일반적으로 두 가지 정보를 포함합니다:

alg: 사용된 서명 알고리즘 (예: HMAC SHA256, RSA)
typ: 토큰의 타입 (JWT)

예시:

{
  "alg": "HS256",
  "typ": "JWT"
}

이 JSON 객체는 Base64Url로 인코딩되어 JWT의 첫 번째 부분이 됩니다.

2. 페이로드 (Payload)

페이로드는 토큰에 담을 클레임(claims)을 포함합니다. 클레임은 사용자 정보, 권한, 발급 시간, 만료 시간 등을 의미합니다. 클레임은 다음과 같이 세 가지 유형으로 나뉩니다:

등록된 클레임 (Registered claims): 표준화된 클레임으로, 권장 사항이지만 필수는 아님 (예: iss(발급자), exp(만료 시간), sub(주제), aud(대상))
공개 클레임 (Public claims): 충돌을 피하기 위해 URI 형식으로 정의
비공개 클레임 (Private claims): 발급자와 수신자 간에 합의된 사용자 정의 클레임

예시:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1516239022
}

이 내용도 Base64Url로 인코딩되어 두 번째 부분이 됩니다.

3. 서명 (Signature)

서명은 헤더와 페이로드의 인코딩된 값을 조합한 후, 비밀 키 또는 개인 키를 사용해 서명한 값입니다. 이를 통해 토큰이 변조되지 않았는지 검증할 수 있습니다.

서명 생성 예시 (HMAC SHA256 기준):

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

작동 원리

JWT는 주로 다음과 같은 흐름으로 사용됩니다:

사용자가 로그인 요청을 서버에 전송
서버가 자격 증명(예: ID/비밀번호)을 검증 후, 유효하면 JWT 발급
클라이언트는 이후 모든 요청에 JWT를 Authorization 헤더에 포함 (Bearer <token>)
서버는 수신한 JWT를 검증하고, 유효하면 요청을 처리

이 방식은 세션 기반 인증과 달리 서버 측에 세션 정보를 저장할 필요가 없어 무상태(stateless) 구조를 가능하게 하며, 확장성과 성능에 유리합니다.

장점과 단점

장점

무상태성: 서버가 클라이언트 상태를 저장하지 않아도 됨
확장성: 여러 서버 간에 세션 공유가 필요 없음
자체 포함 정보: 페이로드에 필요한 정보를 포함할 수 있음
다양한 플랫폼 지원: 언어와 플랫폼에 독립적

단점

토큰 크기: 세션 ID보다 크기 때문에 네트워크 오버헤드 발생 가능
만료 관리 어려움: 한 번 발급된 토큰은 만료 전까지 서버에서 강제로 무효화하기 어려움
보안 취약점: 서명 키가 유출되면 위조 가능, 적절한 알고리즘 선택 필수

보안 고려사항

암호화 알고리즘 선택: HS256은 비밀 키 기반, RS256은 공개키 기반. 후자는 더 안전하지만 복잡함
서명 키 보호: 비밀 키는 절대 외부에 노출되어서는 안 됨
만료 시간 설정: 짧은 exp 값을 설정하여 노출 위험 최소화
토큰 저장: 클라이언트 측에서는 HttpOnly 쿠키 또는 [localStorage](/doc/%EA%B8%B0%EC%88%A0/%EC%9B%B9%EA%B8%B0%EC%88%A0/%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%20%EC%A0%80%EC%9E%A5%EC%86%8C/localStorage) 중 보안에 맞게 선택

참고 자료

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# JWT

## 개요

JWT(JavaScript Object Notation Web Token)는 네트워크 상에서 정보를 JSON 객체 형태로 안전하게 전달하기 위한 개방형 표준(RFC 7519)입니다. 주로 사용자 인증 및 정보 교환에 활용되며, 서버와 클라이언트 간의 상태 비저장(stateless) 인증을 구현하는 데 널리 사용됩니다. JWT는 자체적으로 정보를 포함하므로, 수신 측에서 추가적인 데이터베이스 조회 없이도 토큰의 유효성과 사용자 정보를 확인할 수 있습니다.

JWT는 세 부분으로 구성되며, 각 부분은 점(`.`)으로 구분됩니다: **헤더**(Header), **페이로드**(Payload), **서명**(Signature). 이 구조 덕분에 토큰이 위조되지 않았는지 검증할 수 있으며, 신뢰할 수 있는 주체에 의해 발급되었음을 보장합니다.

---

## 구조

JWT는 다음과 같은 세 가지 구성 요소로 이루어져 있습니다:

```
xxxxx.yyyyy.zzzzz
```

### 1. 헤더 (Header)

헤더는 일반적으로 두 가지 정보를 포함합니다:

- `alg`: 사용된 서명 알고리즘 (예: HMAC SHA256, RSA)
- `typ`: 토큰의 타입 (JWT)

예시:
```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

이 JSON 객체는 Base64Url로 인코딩되어 JWT의 첫 번째 부분이 됩니다.

### 2. 페이로드 (Payload)

페이로드는 토큰에 담을 클레임(claims)을 포함합니다. 클레임은 사용자 정보, 권한, 발급 시간, 만료 시간 등을 의미합니다. 클레임은 다음과 같이 세 가지 유형으로 나뉩니다:

- **등록된 클레임 (Registered claims)**: 표준화된 클레임으로, 권장 사항이지만 필수는 아님 (예: `iss`(발급자), `exp`(만료 시간), `sub`(주제), `aud`(대상))
- **공개 클레임 (Public claims)**: 충돌을 피하기 위해 URI 형식으로 정의
- **비공개 클레임 (Private claims)**: 발급자와 수신자 간에 합의된 사용자 정의 클레임

예시:
```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1516239022
}
```

이 내용도 Base64Url로 인코딩되어 두 번째 부분이 됩니다.

### 3. 서명 (Signature)

서명은 헤더와 페이로드의 인코딩된 값을 조합한 후, 비밀 키 또는 개인 키를 사용해 서명한 값입니다. 이를 통해 토큰이 변조되지 않았는지 검증할 수 있습니다.

서명 생성 예시 (HMAC SHA256 기준):
```
HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)
```

---

## 작동 원리

JWT는 주로 다음과 같은 흐름으로 사용됩니다:

1. 사용자가 로그인 요청을 서버에 전송
2. 서버가 자격 증명(예: ID/비밀번호)을 검증 후, 유효하면 JWT 발급
3. 클라이언트는 이후 모든 요청에 JWT를 `Authorization` 헤더에 포함 (`Bearer <token>`)
4. 서버는 수신한 JWT를 검증하고, 유효하면 요청을 처리

이 방식은 세션 기반 인증과 달리 서버 측에 세션 정보를 저장할 필요가 없어 **무상태(stateless)** 구조를 가능하게 하며, 확장성과 성능에 유리합니다.

---

## 장점과 단점

### 장점

- **무상태성**: 서버가 클라이언트 상태를 저장하지 않아도 됨
- **확장성**: 여러 서버 간에 세션 공유가 필요 없음
- **자체 포함 정보**: 페이로드에 필요한 정보를 포함할 수 있음
- **다양한 플랫폼 지원**: 언어와 플랫폼에 독립적

### 단점

- **토큰 크기**: 세션 ID보다 크기 때문에 네트워크 오버헤드 발생 가능
- **만료 관리 어려움**: 한 번 발급된 토큰은 만료 전까지 서버에서 강제로 무효화하기 어려움
- **보안 취약점**: 서명 키가 유출되면 위조 가능, 적절한 알고리즘 선택 필수

---

## 보안 고려사항

- **암호화 알고리즘 선택**: `HS256`은 비밀 키 기반, `RS256`은 공개키 기반. 후자는 더 안전하지만 복잡함
- **서명 키 보호**: 비밀 키는 절대 외부에 노출되어서는 안 됨
- **만료 시간 설정**: 짧은 `exp` 값을 설정하여 노출 위험 최소화
- **토큰 저장**: 클라이언트 측에서는 `HttpOnly` 쿠키 또는 `localStorage` 중 보안에 맞게 선택

---

## 관련 기술 및 표준

- **OAuth 2.0**: JWT는 OAuth 2.0 프레임워크 내에서 액세스 토큰으로 자주 사용됨
- **OpenID Connect**: JWT 기반의 사용자 인증 프로토콜
- **JWS (JSON Web Signature)**: JWT의 서명 메커니즘 기반
- **JWE (JSON Web Encryption)**: JWT의 암호화 버전 (선택적)

---

## 참고 자료

- [RFC 7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519)
- [Auth0 - JWT Introduction](https://auth0.com/docs/tokens/concepts/jwts)
- [OWASP - JWT Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)

AI 생성 콘텐츠 안내

이 문서는 AI 모델(qwen-3-235b-a22b-instruct-2507)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나

JWT

JWT

개요

구조