Access token ਅਤੇ refresh token ਇਕੱਠੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

ਦੋਵੇਂ token ਇੱਕ ਸਧਾਰਨ lifecycle ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ: ਇੱਕ **ਥੋੜ੍ਹ-ਚਿਰਾ access token** ਹਰ API ਕਾਲ ਨੂੰ ਅਧਿਕਾਰਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ **ਲੰਬ-ਚਿਰਾ refresh token** ਹੱਦ ਲੰਘਣ 'ਤੇ ਚੁੱਪਚਾਪ ਨਵੇਂ access token ਬਣਾ ਦਿੰਦਾ ਹੈ — ਤਾਂ ਜੋ ਯੂਜ਼ਰ credential ਮੁੜ ਦਾਖ਼ਲ ਕੀਤੇ ਬਿਨਾਂ logged in ਰਹੇ।

## ਪ੍ਰਵਾਹ (Flow)

```
┌─────────┐  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 }
     ▼
┌────────────┐  ਪੁਸ਼ਟੀ + rotate
│ Auth server│ ──── ਨਵਾਂ access (+ ਨਵਾਂ refresh) ────▶ ਕਾਲ ਮੁੜ ਕਰੋ
└────────────┘
```

1. **Login** — ਯੂਜ਼ਰ ਇੱਕ ਵਾਰ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ; server ਇੱਕ **access token** (ਛੋਟਾ TTL) ਅਤੇ ਇੱਕ **refresh token** (ਲੰਬਾ TTL) ਵਾਪਸ ਕਰਦਾ ਹੈ।
2. **API ਵਰਤੋ** — client ਹਰ request 'ਤੇ access token ਨੂੰ `Authorization: Bearer …` ਵਿੱਚ ਭੇਜਦਾ ਹੈ। API ਇਸ ਨੂੰ stateless ਢੰਗ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ (signature + `exp`) ਅਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ — ਕਿਸੇ session store ਦੀ ਲੋੜ ਨਹੀਂ।
3. **ਹੱਦ ਲੰਘਣ 'ਤੇ refresh** — ਜਦੋਂ API `401` ਵਾਪਸ ਕਰਦਾ ਹੈ (ਜਾਂ client ਦੇਖਦਾ ਹੈ ਕਿ `exp` ਨੇੜੇ ਹੈ), client **refresh token** ਨੂੰ auth server ਦੇ `/token` endpoint 'ਤੇ POST ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਤਾਜ਼ਾ access token ਲੈਂਦਾ ਹੈ, ਫਿਰ ਮੂਲ request ਮੁੜ ਕਰਦਾ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਕੁਝ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।
4. **Logout / revoke** — 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 ਨੂੰ revoke ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਮੁੜ login ਕਰਵਾਉਂਦਾ ਹੈ। ਇਹ ਚੋਰੀ ਹੋਏ refresh token ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।

## ਸਟੋਰੇਜ

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie ਤਾਂ ਜੋ JavaScript (ਅਤੇ ਇਸ ਲਈ XSS) ਇਸ ਨੂੰ ਪੜ੍ਹ ਨਾ ਸਕੇ।
- **Access token** → client 'ਤੇ memory ਵਿੱਚ ਰੱਖਿਆ; ਛੋਟਾ ਜੀਵਨ ਉਜਾਗਰੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।
- ਜੇ ਬਚ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿਸੇ ਨੂੰ ਵੀ `localStorage` ਵਿੱਚ ਕਦੇ ਨਾ ਰੱਖੋ — ਇਹ ਕਿਸੇ ਵੀ injected script ਦੁਆਰਾ ਪੜ੍ਹਨਯੋਗ ਹੈ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇਹ flow ਆਧੁਨਿਕ SPA, ਮੋਬਾਈਲ ਐਪ ਅਤੇ API ਵਿੱਚ session ਪ੍ਰਬੰਧਨ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ, ਇਸ ਲਈ interviewer ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਇਸ ਨੂੰ ਅੰਤ-ਤੋਂ-ਅੰਤ ਤੱਕ ਟਰੇਸ ਕਰੋ: login 'ਤੇ ਦੋਵੇਂ ਜਾਰੀ ਕਰੋ, access token ਨਾਲ ਅਧਿਕਾਰਤ ਕਰੋ, ਹੱਦ ਲੰਘਣ 'ਤੇ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ refresh ਕਰੋ, ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ rotate + revoke ਕਰੋ। ਵੇਰਵਿਆਂ ਨੂੰ ਸਹੀ ਕਰਨਾ — stateless verification, ਸਿਰਫ਼ token endpoint 'ਤੇ refresh, ਮੁੜ-ਵਰਤੋਂ ਦੀ ਪਛਾਣ ਸਹਿਤ rotation, ਅਤੇ `httpOnly` ਸਟੋਰੇਜ — ਇੱਕ ਸੁਚਾਰੂ, ਸੁਰੱਖਿਅਤ session ਅਤੇ ਇੱਕ ਅਜਿਹੀ session ਵਿੱਚ ਫ਼ਰਕ ਹੈ ਜਿੱਥੇ ਇੱਕ ਚੋਰੀ ਹੋਏ token ਦਾ ਮਤਲਬ ਲੰਬ-ਚਿਰਾ account takeover ਹੈ।

ਪ੍ਰਵਾਹ (Flow)

Refresh token rotation

ਸਟੋਰੇਜ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ