Access tokens மற்றும் refresh tokens எப்படி ஒன்றாக வேலை செய்கின்றன?

Question

IT Interview Practice · Accepted Answer

இந்த இரண்டு tokens ஒரு எளிய வாழ்க்கைச் சுழற்சியைப் பின்பற்றுகின்றன: ஒரு **குறுகிய கால access token** ஒவ்வொரு API அழைப்பையும் அங்கீகரிக்கிறது, மற்றும் ஒரு **நீண்ட கால refresh token** அவை காலாவதியாகும் போது அமைதியாக புதிய access tokens-ஐ உருவாக்குகிறது — இதனால் பயனர் சான்றுகளை மீண்டும் உள்ளிடாமல் login-இல் இருக்கிறார்.

## ஓட்டம்

```
┌─────────┐  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 ஒவ்வொரு request-லும் access token-ஐ `Authorization: Bearer …`-இல் அனுப்புகிறது. API அதை statelessly-ஆக (signature + `exp`) சரிபார்த்து பதிலளிக்கிறது — session store தேவையில்லை.
3. **காலாவதியில் refresh** — API `401` திருப்பித் தரும்போது (அல்லது client `exp` நெருங்குவதைப் பார்க்கும்போது), client **refresh token**-ஐ auth server-இன் `/token` endpoint-க்கு POST செய்து ஒரு புதிய access token பெறுகிறது, பின்னர் அசல் request-ஐ மீண்டும் முயற்சிக்கிறது. பயனர் எதையும் கவனிக்கவில்லை.
4. **Logout / ரத்து** — server refresh token-ஐ நீக்குகிறது அல்லது denylist செய்கிறது; அடுத்த refresh தோல்வியடைந்து session முடிகிறது (தற்போதைய access token இன்னும் சில நிமிடங்களில் தானாகவே இறக்கிறது).

```js
// Client interceptor: 401-இல் ஒருமுறை refresh செய்து, பின்னர் மீண்டும் முயற்சி.
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 family-ஐயும் ரத்து செய்து மீண்டும் login-ஐ கட்டாயப்படுத்துகிறது. இது திருடப்பட்ட refresh token-இன் சேதத்தை வரம்பிடுகிறது.

## சேமிப்பு

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie, இதனால் JavaScript (மற்றும் அதன் மூலம் XSS) அதைப் படிக்க முடியாது.
- **Access token** → client-இல் memory-இல் வைக்கப்படுகிறது; குறுகிய வாழ்க்கை வெளிப்பாட்டை வரம்பிடுகிறது.
- தவிர்க்க முடிந்தால் எதையும் `localStorage`-இல் வைக்க வேண்டாம் — அது எந்த inject செய்யப்பட்ட script-க்கும் படிக்கக்கூடியது.

## இது ஏன் முக்கியம்

இந்த ஓட்டம் நவீன SPAs, mobile apps மற்றும் API-களில் session மேலாண்மையின் முதுகெலும்பு, எனவே interviewers நீங்கள் இதை முழுமையாகக் கண்டறிய எதிர்பார்க்கிறார்கள்: login-இல் இரண்டையும் வழங்கு, access token-உடன் அங்கீகரி, காலாவதியில் வெளிப்படையாக refresh செய், மற்றும் பாதுகாப்பிற்காக rotate + ரத்து செய். விவரங்களை சரியாகப் பெறுவது — stateless சரிபார்ப்பு, refresh token endpoint-இல் மட்டுமே, மறுபயன்பாடு கண்டறிதலுடன் rotation, மற்றும் `httpOnly` சேமிப்பு — ஒரு மென்மையான, பாதுகாப்பான session-க்கும் ஒரு திருடப்பட்ட token என்பது நீண்ட கால கணக்கு கையகப்படுத்தலைக் குறிக்கும் ஒன்றுக்கும் இடையிலான வித்தியாசம்.

ஓட்டம்

Refresh token rotation

சேமிப்பு

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்