Kuinka access tokenit ja refresh tokenit toimivat yhdessä?

Question

IT Interview Practice · Accepted Answer

Kaksi tokenia seuraa yksinkertaista elinkaarta: **lyhytikäinen access token** valtuuttaa jokaisen API-kutsun, ja **pitkäikäinen refresh token** luo hiljaa uusia access tokeneita niiden vanhentuessa — joten käyttäjä pysyy kirjautuneena syöttämättä tunnuksia uudelleen.

## Kulku

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — käyttäjä autentikoituu kerran; palvelin palauttaa **access tokenin** (lyhyt TTL) ja **refresh tokenin** (pitkä TTL).
2. **API-kutsut** — client lähettää access tokenin `Authorization: Bearer …`:ssa jokaisessa pyynnössä. API vahvistaa sen tilattomasti (allekirjoitus + `exp`) ja vastaa — ei tarvita session-varastoa.
3. **Refresh vanhentuessa** — kun API palauttaa `401`:n (tai client näkee `exp`:n olevan lähellä), client POSTaa **refresh tokenin** autentikointipalvelimen `/token`-endpointtiin ja saa tuoreen access tokenin, sitten yrittää alkuperäistä pyyntöä uudelleen. Käyttäjä ei huomaa mitään.
4. **Uloskirjautuminen / mitätöinti** — palvelin poistaa refresh tokenin tai lisää sen estolistalle; seuraava refresh epäonnistuu ja istunto päättyy (nykyinen access token kuolee silti itsestään minuuteissa).

```js
// Client-interceptor: refreshaa kerran 401:llä, sitten yritä uudelleen.
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));   // yritä uudelleen
  }
  return res;
}
```

## Refresh tokenin kierrätys

Paras käytäntö on **kierrätys**: jokainen refresh-kutsu palauttaa *uuden* refresh tokenin ja mitätöi vanhan. Jos vanha (jo käytetty) refresh token esitetään uudelleen, se signaloi varkautta — palvelin mitätöi koko token-perheen ja pakottaa uudelleenkirjautumisen. Tämä rajoittaa varastetun refresh tokenin vahinkoa.

## Tallennus

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` -cookie, jotta JavaScript (ja siten XSS) ei voi lukea sitä.
- **Access token** → pidetään muistissa clientilla; lyhyt elinaika rajoittaa altistumista.
- Älä koskaan laita kumpaakaan `localStorage`:een jos voit välttää sen — mikä tahansa injektoitu skripti voi lukea sen.

## Miksi se on tärkeää

Tämä kulku on session-hallinnan selkäranka moderneissa SPA:issa, mobiilisovelluksissa ja API:issa, joten haastattelijat odottavat sinun jäljittävän sen päästä päähän: myönnä molemmat kirjautuessa, valtuuta access tokenilla, refreshaa läpinäkyvästi vanhentuessa, ja kierrätä + mitätöi turvallisuuden vuoksi. Yksityiskohtien tekeminen oikein — tilaton vahvistus, refresh vain token-endpointissa, kierrätys uudelleenkäytön havaitsemisella, ja `httpOnly`-tallennus — on ero sujuvan, turvallisen istunnon ja sellaisen välillä, jossa yksi varastettu token tarkoittaa pitkäaikaista tilin haltuunottoa.

Kulku

Refresh tokenin kierrätys

Tallennus

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset