ทำไมคุณจึงต้องมีทั้ง access token และ refresh token?

Question

IT Interview Practice · Accepted Answer

token ทั้งสองมีอยู่เพื่อแก้ความขัดแย้งโดยตรง: access token ต้อง **ถูกส่งในทุก request** (จึงถูกเปิดเผยมาก) แต่คุณก็ต้องการ session ที่ **อยู่ได้นาน** โดยไม่ต้องบังคับให้ login บ่อย ๆ คุณไม่สามารถมีทั้งสองอย่างอย่างปลอดภัยใน token เดียวได้ — คุณจึงแบ่งหน้าที่กัน

## สองบทบาท

- **Access token** — อายุสั้น (โดยทั่วไป 5–15 นาที), ส่งใน header `Authorization` ในทุกการเรียก API เพราะมันถูกส่งอยู่ตลอด การรั่วไหลจึงมีโอกาสสูง; การเก็บมันให้สั้นหมายความว่า token ที่ถูกขโมยจะหมดอายุแทบจะทันที
- **Refresh token** — อายุยาว (วัน/สัปดาห์), ส่ง **เฉพาะ** ไปยัง token endpoint ของ auth server เพื่อขอ access token ใหม่ มันเดินทางน้อยครั้ง จึงสามารถเก็บได้ปลอดภัยกว่า และสามารถเพิกถอนได้ที่ฝั่ง server

```
Login ──▶ access (15m) + refresh (30d)
ทุกการเรียก API ──▶ ส่ง access
Access หมดอายุ ──▶ ส่ง refresh ──▶ access ใหม่ (+ refresh ที่หมุนเวียน)
```

## ทำไมไม่ใช้ token เดียว?

| | access token อายุยาวหนึ่งตัว | Access + refresh |
|---|---|---|
| การเปิดเผย | ส่งทุก request, อยู่นาน → หน้าต่างการขโมยกว้าง | Access อายุสั้น; refresh ส่งน้อยครั้ง |
| การเพิกถอน | ยาก (stateless JWT ไม่สามารถยกเลิกการออกได้) | เพิกถอน refresh token; access ตายภายในไม่กี่นาที |
| UX | login ใหม่บ่อยหากสั้น | ยังคง login อยู่โดยไม่ต้องกรอก credentials อีก |
| รัศมีความเสียหายของการรั่ว | ใหญ่ | เล็ก (access หมดอายุเร็ว) |

- **access token สั้นตัวเดียว ไม่มี refresh** → ปลอดภัย แต่ผู้ใช้ถูก logout ทุกไม่กี่นาที UX แย่มาก
- **access token ยาวตัวเดียว** → UX ดีเยี่ยม แต่ token ที่รั่วมีอายุใช้งานยาวนานและเพิกถอนได้ยาก
- **Access + refresh** → หน้าต่างการเปิดเผยสั้น *และ* session ยาว refresh token คือความลับอายุยาวเพียงตัวเดียว และมันอยู่ในที่ปลอดภัยแห่งเดียว

## การแบ่งนี้เปิดโอกาสให้อะไร

- **การเพิกถอนแม้ access token จะ stateless** คุณไม่สามารถทำให้ JWT access token ใช้ไม่ได้ก่อนหมดอายุ แต่คุณ *สามารถ* ลบ/ปฏิเสธ refresh token ได้ ดังนั้น session จะสิ้นสุดที่การ refresh ครั้งถัดไป (ภายในไม่กี่นาที)
- **Refresh token rotation** — ออก refresh token ใหม่ทุกครั้งที่ใช้ และตรวจจับการใช้ซ้ำของตัวเก่า (สัญญาณของการขโมย) แล้วเพิกถอนทั้งสายโซ่
- **การเปิดเผยน้อยที่สุด** — ความลับอายุยาว (refresh) ถูกส่งไปยัง endpoint เดียวเท่านั้น ในอุดมคติควรเก็บใน cookie แบบ `httpOnly` ให้พ้นมือ XSS

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

นี่คือการออกแบบ auth สมัยใหม่มาตรฐาน และผู้สัมภาษณ์ถามเพื่อดูว่าคุณเข้าใจ *ทำไม* ไม่ใช่แค่ *อย่างไร* ข้อคิดสำคัญคือการแลกเปลี่ยน: ความเป็น stateless และการเปิดเผยสั้น (access) เทียบกับ session ยาวและความสามารถในการเพิกถอน (refresh) การทำผิด — access token อายุยาว, ไม่มี rotation, เก็บ refresh ใน `localStorage` — เปลี่ยน token ที่รั่วเพียงตัวเดียวให้กลายเป็นการยึดบัญชีระยะยาว การระบุการแบ่งนี้และสิ่งที่แต่ละ token มอบให้ คือสิ่งที่วิศวกรที่ตระหนักด้านความปลอดภัยถูกคาดหวังให้รู้

	access token อายุยาวหนึ่งตัว	Access + refresh
การเปิดเผย	ส่งทุก request, อยู่นาน → หน้าต่างการขโมยกว้าง	Access อายุสั้น; refresh ส่งน้อยครั้ง
การเพิกถอน	ยาก (stateless JWT ไม่สามารถยกเลิกการออกได้)	เพิกถอน refresh token; access ตายภายในไม่กี่นาที
UX	login ใหม่บ่อยหากสั้น	ยังคง login อยู่โดยไม่ต้องกรอก credentials อีก
รัศมีความเสียหายของการรั่ว	ใหญ่	เล็ก (access หมดอายุเร็ว)

สองบทบาท

ทำไมไม่ใช้ token เดียว?

การแบ่งนี้เปิดโอกาสให้อะไร

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

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