access token และ refresh token ทำงานร่วมกันอย่างไร?

Question

IT Interview Practice · Accepted Answer

token ทั้งสองดำเนินตามวงจรชีวิตที่เรียบง่าย: **access token อายุสั้น** อนุญาตแต่ละการเรียก API และ **refresh token อายุยาว** สร้าง access token ใหม่อย่างเงียบ ๆ เมื่อมันหมดอายุ — เพื่อให้ผู้ใช้ยังคง login อยู่โดยไม่ต้องกรอก credentials อีก

## กระแสการทำงาน

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. เรียก API: Authorization: Bearer <access>
     ▼
┌────────────┐  ตรวจ signature + exp   (ไม่มี DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access ยังใช้ได้)
│ API        │ ──── 401 ───────▶ (access หมดอายุ)
└────────────┘
     │  3. เมื่อ 401: POST /token { refresh }
     ▼
┌────────────┐  ตรวจ + หมุนเวียน
│ Auth server│ ──── access ใหม่ (+ refresh ใหม่) ────▶ ลองเรียกใหม่
└────────────┘
```

1. **Login** — ผู้ใช้ authenticate หนึ่งครั้ง; server คืน **access token** (TTL สั้น) และ **refresh token** (TTL ยาว)
2. **เรียก API** — client ส่ง access token ใน `Authorization: Bearer …` ในทุก request API ตรวจสอบมันแบบ stateless (signature + `exp`) แล้วตอบกลับ — ไม่ต้องมี session store
3. **Refresh เมื่อหมดอายุ** — เมื่อ API คืน `401` (หรือ client เห็นว่า `exp` ใกล้ถึง) client จะ POST **refresh token** ไปยัง endpoint `/token` ของ auth server และได้ access token ใหม่ แล้วลองเรียก request เดิมใหม่ ผู้ใช้ไม่รู้สึกถึงอะไรเลย
4. **Logout / เพิกถอน** — server ลบหรือใส่ refresh token ใน denylist; การ refresh ครั้งถัดไปล้มเหลวและ session สิ้นสุด (access token ปัจจุบันยังคงตายเองภายในไม่กี่นาที)

```js
// Client interceptor: refresh หนึ่งครั้งเมื่อ 401 แล้วลองใหม่
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // ลองใหม่
  }
  return res;
}
```

## Refresh token rotation

แนวปฏิบัติที่ดีที่สุดคือ **rotation**: การเรียก refresh แต่ละครั้งคืน refresh token *ตัวใหม่* และทำให้ตัวเก่าใช้ไม่ได้ หากมีการยื่น refresh token ตัวเก่า (ที่ใช้ไปแล้ว) อีกครั้ง นั่นเป็นสัญญาณของการขโมย — server จะเพิกถอน token ทั้งตระกูลและบังคับ login ใหม่ สิ่งนี้จำกัดความเสียหายของ refresh token ที่ถูกขโมย

## การจัดเก็บ

- **Refresh token** → cookie แบบ `httpOnly`, `Secure`, `SameSite` เพื่อไม่ให้ JavaScript (และดังนั้น XSS) อ่านมันได้
- **Access token** → เก็บไว้ในหน่วยความจำบน client; อายุสั้นจำกัดการเปิดเผย
- อย่าใส่ทั้งสองอย่างใน `localStorage` หากหลีกเลี่ยงได้ — มันอ่านได้โดย script ที่ถูกฉีดเข้ามาใด ๆ

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

กระแสนี้คือกระดูกสันหลังของการจัดการ session ใน SPA, mobile app และ API สมัยใหม่ ดังนั้นผู้สัมภาษณ์คาดหวังให้คุณไล่ตามมันตั้งแต่ต้นจนจบ: ออกทั้งสองตัวตอน login, อนุญาตด้วย access token, refresh อย่างโปร่งใสเมื่อหมดอายุ และ rotate + เพิกถอนเพื่อความปลอดภัย การทำรายละเอียดให้ถูกต้อง — การตรวจสอบแบบ stateless, refresh เฉพาะที่ token endpoint, rotation พร้อมการตรวจจับการใช้ซ้ำ และการจัดเก็บแบบ `httpOnly` — คือความแตกต่างระหว่าง session ที่ราบรื่นและปลอดภัยกับ session ที่ token ที่ถูกขโมยเพียงตัวเดียวหมายถึงการยึดบัญชีระยะยาว

กระแสการทำงาน

Refresh token rotation

การจัดเก็บ

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

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