Access tokens na refresh tokens hufanya kazi pamoja vipi?

Question

IT Interview Practice · Accepted Answer

Tokens hizi mbili hufuata mzunguko rahisi wa maisha: **access token ya muda mfupi** huidhinisha kila wito wa API, na **refresh token ya muda mrefu** hutengeneza kimyakimya access tokens mpya zinapoisha — kwa hivyo mtumiaji hubaki ameingia bila kuingiza credentials tena.

## Mtiririko

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. wito wa API: Authorization: Bearer <access>
     ▼
┌────────────┐  thibitisha signature + exp   (hakuna DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access bado ni halali)
│ API        │ ──── 401 ───────▶ (access imeisha)
└────────────┘
     │  3. wakati wa 401: POST /token { refresh }
     ▼
┌────────────┐  thibitisha + zungusha
│ Auth server│ ──── access mpya (+ refresh mpya) ────▶ jaribu wito tena
└────────────┘
```

1. **Login** — mtumiaji huthibitisha mara moja; server hurudisha **access token** (TTL fupi) na **refresh token** (TTL ndefu).
2. **Fikia API** — client hutuma access token katika `Authorization: Bearer …` kwa kila request. API huithibitisha bila hali (signature + `exp`) na kujibu — hakuna hifadhi ya session inayohitajika.
3. **Refresh inapoisha** — API inaporudisha `401` (au client huona `exp` inakaribia), client hu-POST **refresh token** kwa endpoint ya `/token` ya server ya auth na kupata access token mpya, kisha hujaribu request ya awali tena. Mtumiaji haoni chochote.
4. **Logout / futa** — server hufuta au huweka refresh token kwenye denylist; refresh inayofuata inashindwa na session inaisha (access token ya sasa bado hufa yenyewe ndani ya dakika).

```js
// Client interceptor: refresh mara moja wakati wa 401, kisha jaribu tena.
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));   // jaribu tena
  }
  return res;
}
```

## Refresh token rotation

Utendaji bora ni **rotation**: kila wito wa refresh hurudisha refresh token *mpya* na kubatilisha ya zamani. Ikiwa refresh token ya zamani (iliyotumika tayari) itatolewa tena, hiyo huashiria wizi — server hufuta familia nzima ya tokens na kulazimisha login upya. Hii hupunguza uharibifu wa refresh token iliyoibwa.

## Uhifadhi

- **Refresh token** → cookie ya `httpOnly`, `Secure`, `SameSite` ili JavaScript (na hivyo XSS) isiweze kuisoma.
- **Access token** → huwekwa kwenye kumbukumbu ya client; maisha mafupi hupunguza kuonyeshwa.
- Kamwe usiweke yoyote katika `localStorage` ikiwa unaweza kuepuka — inaweza kusomwa na script yoyote iliyoingizwa.

## Kwa nini ni muhimu

Mtiririko huu ni uti wa mgongo wa usimamizi wa session katika SPAs za kisasa, apps za simu, na APIs, kwa hivyo wahojiwa wanatarajia ufuatilie kutoka mwanzo hadi mwisho: toa zote mbili wakati wa login, idhinisha kwa access token, refresh kwa uwazi inapoisha, na zungusha + futa kwa usalama. Kupata maelezo sawa — uthibitishaji bila hali, refresh tu kwenye token endpoint, rotation yenye ugunduzi wa matumizi tena, na uhifadhi wa `httpOnly` — ndio tofauti kati ya session laini na salama na ile ambapo token moja iliyoibwa inamaanisha uchukuaji wa akaunti wa muda mrefu.

Mtiririko

Refresh token rotation

Uhifadhi

Kwa nini ni muhimu

Maswali yanayohusiana