Si punojnë së bashku access token-ët dhe refresh token-ët?

Question

IT Interview Practice · Accepted Answer

Të dy token-ët ndjekin një cikël jetësor të thjeshtë: një **access token jetëshkurtër** autorizon çdo thirrje API, dhe një **refresh token jetëgjatë** në heshtje krijon access token të reja kur ato skadojnë — kështu përdoruesi mbetet i loguar pa rifutur kredencialet.

## Rrjedha

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. thirrje API: Authorization: Bearer <access>
     ▼
┌────────────┐  verifikon nënshkrimin + exp   (pa kërkim në DB)
│ Resource   │ ──── 200 OK ────▶ (access ende i vlefshëm)
│ API        │ ──── 401 ───────▶ (access i skaduar)
└────────────┘
     │  3. në 401: POST /token { refresh }
     ▼
┌────────────┐  verifikon + rrotullon
│ Auth server│ ──── access i ri (+ refresh i ri) ────▶ riprovon thirrjen
└────────────┘
```

1. **Login** — përdoruesi autentikohet një herë; serveri kthen një **access token** (TTL i shkurtër) dhe një **refresh token** (TTL i gjatë).
2. **Qasja në API** — klienti dërgon access token-in në `Authorization: Bearer …` në çdo kërkesë. API-ja e verifikon atë pa gjendje (nënshkrim + `exp`) dhe përgjigjet — nuk nevojitet asnjë ruajtje seance.
3. **Rifreskim në skadim** — kur API-ja kthen `401` (ose klienti sheh se `exp` është afër), klienti bën POST të **refresh token-it** te endpoint-i `/token` i serverit të autentikimit dhe merr një access token të freskët, pastaj riprovon kërkesën origjinale. Përdoruesi nuk vëren asgjë.
4. **Logout / revokim** — serveri fshin ose vendos në denylist refresh token-in; rifreskimi tjetër dështon dhe seanca përfundon (access token-i aktual sërish vdes vetë brenda minutash).

```js
// Interceptor-i i klientit: rifresko një herë në 401, pastaj riprovo.
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));   // riprovo
  }
  return res;
}
```

## Rotacioni i refresh token-it

Praktika më e mirë është **rotacioni**: çdo thirrje rifreskimi kthen një refresh token *të ri* dhe e çvlefshmëron të vjetrin. Nëse një refresh token i vjetër (tashmë i përdorur) paraqitet përsëri, kjo sinjalizon vjedhje — serveri revokon të gjithë familjen e token-ëve dhe detyron rihyrje. Kjo kufizon dëmin e një refresh token-i të vjedhur.

## Ruajtja

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` që JavaScript-i (dhe rrjedhimisht XSS-ja) të mos mund ta lexojë.
- **Access token** → mbahet në memorie te klienti; jeta e shkurtër kufizon ekspozimin.
- Kurrë mos vendos asnjërin në `localStorage` nëse mund ta shmangësh — është i lexueshëm nga çdo skript i injektuar.

## Pse ka rëndësi

Kjo rrjedhë është shtylla kurrizore e menaxhimit të seancave në SPA-të moderne, aplikacionet mobile dhe API-të, kështu që intervistuesit presin që ta gjurmosh nga fillimi në fund: lësho të dyja në login, autorizo me access token-in, rifresko në mënyrë transparente në skadim, dhe rrotullo + revoko për siguri. T'i bësh detajet siç duhet — verifikim pa gjendje, rifreskim vetëm te endpoint-i i token-it, rotacion me zbulim ripërdorimi dhe ruajtje `httpOnly` — është ndryshimi mes një seance të rrjedhshme e të sigurt dhe njërës ku një token i vetëm i vjedhur do të thotë marrje afatgjatë e llogarisë.

Rrjedha

Rotacioni i refresh token-it

Ruajtja

Pse ka rëndësi

Pyetje të ngjashme