คุณรักษาความปลอดภัยของ REST API อย่างไร (การยืนยันตัวตน การอนุญาต การขนส่งข้อมูล)?

Question

IT Interview Practice · Accepted Answer

การรักษาความปลอดภัยของ REST API หมายถึงการตอบสามคำถามในทุก request: **คุณเป็นใคร** (authentication), **คุณได้รับอนุญาตให้ทำอะไร** (authorization), และ **ช่องทางเป็นส่วนตัวหรือไม่** (transport) เพราะ REST เป็นแบบ **stateless** credential จึงต้องเดินทางไปกับทุก request แทนที่จะอาศัยอยู่ใน session ของ server

## การขนส่ง: HTTPS เสมอ

ทุกอย่างข้างล่างนี้สมมติว่ามี **TLS/HTTPS** หากไม่มี token และ API key จะเดินทางเป็น plaintext และถูกดักฟังได้ นี่คือสิ่งที่ต่อรองไม่ได้ — bearer token บน HTTP คือ token ที่รั่วแล้ว

## ตัวเลือกการยืนยันตัวตน

**API key** — ความลับแบบ static ใน header เรียบง่าย เหมาะกับ server-to-server และการระบุตัว *แอปพลิเคชัน* ไม่ใช่ user อ่อนแอในตัวเอง (ไม่มีวันหมดอายุ ไม่มี scope) เว้นแต่จับคู่กับสิ่งอื่นเพิ่ม
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — มาตรฐานสำหรับการเข้าถึงแบบ **มอบสิทธิ์ (delegated)** ("ให้ App X อ่านข้อมูลของฉันได้โดยไม่ต้องใช้รหัสผ่านของฉัน") แอปได้ **access token** ผ่าน flow หนึ่ง (เช่น Authorization Code) แล้วส่งมันเป็น bearer token นี่คือวิธีที่ "Sign in with Google" และการ integrate กับบุคคลที่สามทำงาน

**JWT (JSON Web Token)** — *รูปแบบ* token ที่พบบ่อย: token ที่มีเนื้อในตัวเองและมีลายเซ็น พก claim (user id, role, วันหมดอายุ) server ยืนยันลายเซ็น — ไม่ต้องค้นฐานข้อมูล ซึ่งเข้ากับ REST แบบ stateless
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## การอนุญาต: scope และ role

authentication พิสูจน์ตัวตน; **authorization** ตัดสินสิทธิ์เข้าถึง token พก **scope** (`orders:read`, `orders:write`) หรือ role; server ตรวจมันในแต่ละ endpoint และคืน `403 Forbidden` เมื่อไม่เพียงพอ (ต่างจาก `401` สำหรับ auth ที่ขาด/ไม่ถูกต้อง)

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## สิ่งจำเป็นอื่น ๆ

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

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

ความปลอดภัยเป็นจุดที่ความผิดพลาดเล็ก ๆ กลายเป็นการรั่วไหล ผู้สัมภาษณ์จึงใช้ข้อนี้ดูว่าคุณให้เหตุผลกับมันอย่างเป็นโครงสร้างหรือแค่ท่อง buzzword สัญญาณที่พวกเขามองหาคือคุณ **แยกสามชั้นออกจากกัน** — transport (HTTPS, เสมอ), authentication (พิสูจน์ตัวตน แบบ stateless ผ่าน bearer token/JWT/OAuth), และ authorization (scope และ least privilege) — และไม่ปนกัน เช่น ใช้ `401` สำหรับ "ยังไม่ได้ยืนยันตัวตน" กับ `403` สำหรับ "ยืนยันตัวตนแล้วแต่ไม่ได้รับอนุญาต" อย่างถูกต้อง คำตอบที่แข็งแรงแสดงความตระหนักถึงการแลกเปลี่ยนเชิงปฏิบัติ: JWT สะดวกและ stateless แต่เพิกถอนก่อนหมดอายุยาก (จึงใช้อายุสั้นบวก refresh token), API key ระบุแอปไม่ใช่ user, และ OAuth มีอยู่ก็เพื่อให้ user ไม่ต้องมอบรหัสผ่านให้บุคคลที่สาม การผูกมันเข้ากับความ stateless ของ REST — credential บนทุก request ไม่มี session ที่ server — แสดงว่าคุณเข้าใจ *ว่าทำไม* ความปลอดภัยของ API จึงมีรูปร่างแบบนั้น

การขนส่ง: HTTPS เสมอ

ตัวเลือกการยืนยันตัวตน

การอนุญาต: scope และ role

สิ่งจำเป็นอื่น ๆ

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

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