JSON Web Token (JWT) ทำงานอย่างไร?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** เป็น token ที่กระชับ, ปลอดภัยสำหรับ URL, และมีข้อมูลในตัวเอง ซึ่งบรรจุ claims เกี่ยวกับผู้ใช้ เซิร์ฟเวอร์ sign มันหนึ่งครั้ง หลังจากนั้นสามารถ **verify** token ในทุก request ได้โดยไม่ต้องค้นหาฐานข้อมูล — นั่นคือสิ่งที่ทำให้ auth ที่อิงกับ JWT เป็นแบบ *stateless*

## โครงสร้าง: สามส่วนแบบ base64url

JWT คือ `header.payload.signature` สามส่วนที่เข้ารหัสแบบ base64url เชื่อมกันด้วยจุด:

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

- **Header** — อัลกอริทึมในการ sign เช่น `{ "alg": "HS256", "typ": "JWT" }`
- **Payload** — **claims**: แบบมาตรฐานเช่น `sub` (subject/user id), `exp` (หมดอายุ), `iat` (issued-at), `iss` (issuer) พร้อม field แบบกำหนดเองใด ๆ (`role`, `email`)
- **Signature** — คำนวณจาก header และ payload ด้วย secret หรือ private key

> Payload ถูก **encode ไม่ใช่ encrypt** ใครก็ตามสามารถ base64-decode และอ่านมันได้ ดังนั้นอย่าใส่รหัสผ่านหรือความลับไว้ใน JWT เด็ดขาด

## การ sign และ verification ทำงานอย่างไร

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

- **HS256** (symmetric): secret เดียวกันใช้ sign และ verify ง่าย แต่ทุกผู้ verify ต้องถือ secret ไว้
- **RS256** (asymmetric): **private key** ใช้ sign, **public key** ใช้ verify auth server เก็บ private key ไว้ services อื่น verify ด้วย public key และไม่สามารถสร้าง tokens ได้เลย

ในแต่ละ request เซิร์ฟเวอร์คำนวณ signature ใหม่จาก header+payload ที่ได้รับแล้วเปรียบเทียบ หากตรงกันและ `exp` อยู่ในอนาคต token จะได้รับความเชื่อถือ — ไม่ต้องมี session store

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

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

try {
  const claims = jwt.verify(token, SECRET); // โยน error หากถูกดัดแปลงหรือหมดอายุ
  // claims.sub === "123"
} catch (e) {
  // ปฏิเสธ: ไม่ถูกต้องหรือหมดอายุ
}
```

## ส่วนที่ยาก: การเพิกถอน (revocation)

เนื่องจากการ verify เป็นแบบ stateless คุณ **ไม่สามารถ** ทำให้ token ใช้ไม่ได้ก่อนหมดอายุเพียงแค่ "ลบ" มันฝั่งเซิร์ฟเวอร์ วิธีบรรเทาที่พบบ่อย:

- เก็บ access tokens ให้ **อายุสั้น** (5–15 นาที) และจับคู่กับ **refresh token** ที่อายุยาวกว่า
- ดูแล **denylist** ขนาดเล็กของ token ids ที่ถูกเพิกถอน (`jti`) สำหรับการ logout/ถูกบุกรุก — สิ่งนี้นำ state กลับเข้ามาเล็กน้อย
- หมุน signing keys

## trade-offs ในการจัดเก็บ

| การจัดเก็บ | ข้อดี | ข้อเสีย |
|---|---|---|
| `httpOnly` cookie | JS อ่านไม่ได้ (ปลอดภัยกว่าต่อ XSS) | ต้องมีการป้องกัน CSRF |
| `localStorage` | ง่าย ไม่มี CSRF | เปิดเผยต่อ XSS |

## ทำไมจึงสำคัญ

JWTs ขับเคลื่อน authentication แบบ stateless ข้าม APIs, microservices และ SPAs — service สามารถเชื่อถือ request ได้ด้วยการ verify signature เพียงอย่างเดียว โดยไม่มี session store ที่ใช้ร่วมกัน แต่ statelessness แบบเดียวกันนั้นคือกับดักสัมภาษณ์แบบคลาสสิก: tokens เพิกถอนได้ยาก, payload อ่านได้ และความสับสนเรื่อง `alg` หรือการขาดการตรวจสอบวันหมดอายุคือช่องโหว่ที่แท้จริง การรู้ว่า signature ปกป้องอะไรและไม่ปกป้องอะไรอย่างแม่นยำเป็นสิ่งจำเป็นต่อการใช้ JWTs อย่างปลอดภัย

การจัดเก็บ	ข้อดี	ข้อเสีย
`httpOnly` cookie	JS อ่านไม่ได้ (ปลอดภัยกว่าต่อ XSS)	ต้องมีการป้องกัน CSRF
`localStorage`	ง่าย ไม่มี CSRF	เปิดเผยต่อ XSS

โครงสร้าง: สามส่วนแบบ base64url

การ sign และ verification ทำงานอย่างไร

ส่วนที่ยาก: การเพิกถอน (revocation)

trade-offs ในการจัดเก็บ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง