Miksi tarvitset sekä access tokenin että refresh tokenin?

Question

IT Interview Practice · Accepted Answer

Kaksi tokenia on olemassa ratkaisemaan suoran ristiriidan: access token täytyy **lähettää jokaisessa pyynnössä** (joten se altistuu paljon), mutta haluat myös istuntoja, jotka **kestävät kauan** ilman toistuvia kirjautumisia. Et voi saada molempia turvallisesti yhdessä tokenissa — joten jaat tehtävän.

## Kaksi roolia

- **Access token** — lyhytikäinen (tyypillisesti 5–15 minuuttia), lähetetään `Authorization`-headerissa jokaisessa API-kutsussa. Koska sitä välitetään jatkuvasti, vuoto on todennäköinen; sen lyhyys tarkoittaa, että varastettu vanhenee lähes heti.
- **Refresh token** — pitkäikäinen (päiviä/viikkoja), lähetetään **vain** autentikointipalvelimen token-endpointtiin uusien access tokenien saamiseksi. Se liikkuu harvoin, voidaan tallentaa turvallisemmin, ja voidaan mitätöidä palvelinpuolella.

```
Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
```

## Miksi ei vain yhtä tokenia?

| | Yksi pitkäikäinen access token | Access + refresh |
|---|---|---|
| Altistuminen | Lähetetään joka pyynnössä, elää kauan → suuri varkausikkuna | Access lyhytikäinen; refresh lähetetään harvoin |
| Mitätöinti | Vaikeaa (tilatonta JWT:tä ei voi peruuttaa) | Mitätöi refresh token; access kuolee minuuteissa |
| UX | Usein uudelleenkirjautuminen jos lyhyt | Pysyy kirjautuneena ilman tunnusten uudelleensyöttöä |
| Vuodon vaikutussäde | Suuri | Pieni (access vanhenee nopeasti) |

- **Yksi lyhyt access token, ei refreshia** → turvallinen, mutta käyttäjä kirjautuu ulos muutaman minuutin välein. Kauhea UX.
- **Yksi pitkä access token** → hyvä UX, mutta vuotanut token on voimassa kauan eikä sitä voi helposti mitätöidä.
- **Access + refresh** → lyhyt altistumisikkuna *ja* pitkät istunnot. Refresh token on ainoa pitkäikäinen salaisuus, ja se elää yhdessä turvallisessa paikassa.

## Mitä jako mahdollistaa

- **Mitätöinti tilattomista access tokeneista huolimatta.** Et voi mitätöidä JWT-access tokenia ennen sen vanhenemista, mutta *voit* poistaa/estää refresh tokenin, joten istunto päättyy seuraavassa refreshissä (minuuteissa).
- **Refresh tokenin kierrätys** — myönnä uusi refresh token jokaisella käytöllä ja havaitse vanhan uudelleenkäyttö (varkauden merkki), sitten mitätöi koko ketju.
- **Vähäisin altistuminen** — pitkäikäinen salaisuus (refresh) lähetetään täsmälleen yhteen endpointtiin, ihanteellisesti tallennettuna `httpOnly`-cookieen, XSS:n ulottumattomiin.

## Miksi se on tärkeää

Tämä on standardi moderni autentikointimalli, ja haastattelijat kysyvät sitä nähdäkseen, ymmärrätkö *miksi*, eikä vain *miten*. Keskeinen oivallus on kompromissi: tilattomuus ja lyhyt altistuminen (access) vastaan pitkät istunnot ja mitätöitävyys (refresh). Väärin tekeminen — pitkäikäinen access token, ei kierrätystä, refresh tallennettuna `localStorage`:een — muuttaa yhden vuotaneen tokenin pitkäaikaiseksi tilin vaarantumiseksi. Jaon nimeäminen ja se, mitä kukin token tuo, on juuri sitä mitä turvatietoiselta insinööriltä odotetaan.

	Yksi pitkäikäinen access token	Access + refresh
Altistuminen	Lähetetään joka pyynnössä, elää kauan → suuri varkausikkuna	Access lyhytikäinen; refresh lähetetään harvoin
Mitätöinti	Vaikeaa (tilatonta JWT:tä ei voi peruuttaa)	Mitätöi refresh token; access kuolee minuuteissa
UX	Usein uudelleenkirjautuminen jos lyhyt	Pysyy kirjautuneena ilman tunnusten uudelleensyöttöä
Vuodon vaikutussäde	Suuri	Pieni (access vanhenee nopeasti)

Kaksi roolia

Miksi ei vain yhtä tokenia?

Mitä jako mahdollistaa

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset