JSON Web Token(JWT)은 어떻게 동작하나요?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token(JWT)**은 사용자에 관한 claim을 담고 다니는 간결하고 URL-안전하며 자체 완결적인 토큰입니다. 서버는 이를 한 번 서명하며, 이후에는 데이터베이스 조회 없이 매 요청마다 토큰을 **검증**할 수 있습니다 — 이것이 JWT 기반 인증을 *stateless*로 만드는 것입니다.

## 구조: 세 개의 base64url 부분

JWT는 `header.payload.signature`, 즉 점으로 이어진 세 개의 base64url 인코딩 세그먼트입니다:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — 서명 알고리즘, 예: `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **claim**: `sub`(subject/user id), `exp`(만료), `iat`(발급 시각), `iss`(issuer) 같은 표준 항목과 임의의 커스텀 필드(`role`, `email`).
- **Signature** — secret 또는 private key로 header와 payload에 대해 계산됩니다.

> payload는 **인코딩된 것이지 암호화된 것이 아닙니다**. 누구나 base64 디코딩해서 읽을 수 있으므로, 비밀번호나 비밀 값을 JWT에 넣지 마세요.

## 서명과 검증이 작동하는 방식

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256**(대칭): 같은 secret으로 서명하고 검증합니다. 단순하지만 모든 검증자가 secret을 보유해야 합니다.
- **RS256**(비대칭): **private key**가 서명하고 **public key**가 검증합니다. auth 서버는 private key를 보관하고, 다른 서비스는 public key로 검증하며 절대 토큰을 발행할 수 없습니다.

매 요청마다 서버는 받은 header+payload에 대해 서명을 다시 계산해 비교합니다. 일치하고 `exp`가 미래이면 토큰은 신뢰됩니다 — 세션 저장소가 필요 없습니다.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // 변조되었거나 만료되면 예외를 던짐
  // claims.sub === "123"
} catch (e) {
  // 거부: 유효하지 않거나 만료됨
}
```

## 어려운 부분: 폐기(revocation)

검증이 stateless이기 때문에, 서버 측에서 단순히 "삭제"하는 것만으로는 만료 전에 토큰을 **무효화할 수 없습니다**. 흔한 완화책:

- access token을 **짧게 유지**하고(5–15분) 더 오래 사는 **refresh token**과 짝지으세요.
- 로그아웃/유출에 대비해 폐기된 토큰 id(`jti`)의 작은 **denylist**를 유지하세요 — 이는 약간의 상태를 다시 도입합니다.
- 서명 키를 교체(rotate)하세요.

## 저장 트레이드오프

| 저장 | 장점 | 단점 |
|---|---|---|
| `httpOnly` cookie | JS가 읽을 수 없음(XSS에 더 안전) | CSRF 보호 필요 |
| `localStorage` | 단순, CSRF 없음 | XSS에 노출 |

## 왜 중요한가

JWT는 API, 마이크로서비스, SPA 전반의 stateless 인증을 구동합니다 — 서비스는 공유 세션 저장소 없이 서명만 검증하여 요청을 신뢰할 수 있습니다. 하지만 바로 그 stateless함이 전형적인 면접 함정입니다: 토큰은 쉽게 폐기할 수 없고, payload는 읽을 수 있으며, `alg` 혼동이나 누락된 만료 검사는 실제 취약점입니다. 서명이 무엇을 보호하고 무엇을 보호하지 않는지 정확히 아는 것이 JWT를 안전하게 사용하는 데 필수적입니다.

저장	장점	단점
`httpOnly` cookie	JS가 읽을 수 없음(XSS에 더 안전)	CSRF 보호 필요
`localStorage`	단순, CSRF 없음	XSS에 노출

구조: 세 개의 base64url 부분

서명과 검증이 작동하는 방식

어려운 부분: 폐기(revocation)

저장 트레이드오프

왜 중요한가

관련 질문