Dlaczego potrzebujesz zarówno tokena dostępu, jak i tokena odświeżającego?

Question

IT Interview Practice · Accepted Answer

Dwa tokeny istnieją, aby rozwiązać bezpośredni konflikt: token dostępu musi być **wysyłany przy każdym żądaniu** (więc jest mocno narażony), a jednocześnie chcesz sesji, które **trwają długo** bez wymuszania częstego logowania. Nie da się mieć obu bezpiecznie w jednym tokenie — więc dzielisz zadanie.

## Dwie role

- **Token dostępu** — krótko żyjący (zwykle 5–15 minut), wysyłany w nagłówku `Authorization` przy każdym wywołaniu API. Ponieważ jest przesyłany bez przerwy, wyciek jest prawdopodobny; utrzymywanie go krótkim oznacza, że skradziony wygasa niemal natychmiast.
- **Token odświeżający** — długo żyjący (dni/tygodnie), wysyłany **tylko** do punktu tokenów serwera uwierzytelniania w celu uzyskania nowych tokenów dostępu. Podróżuje rzadko, może być przechowywany bezpieczniej i może zostać unieważniony po stronie serwera.

```
Login ──▶ access (15m) + refresh (30d)
Każde wywołanie API ──▶ wyślij access
Access wygasł ──▶ wyślij refresh ──▶ nowy access (+ zrotowany refresh)
```

## Dlaczego nie tylko jeden token?

| | Jeden długo żyjący token dostępu | Access + refresh |
|---|---|---|
| Narażenie | Wysyłany przy każdym żądaniu, żyje długo → duże okno kradzieży | Access krótko żyjący; refresh rzadko wysyłany |
| Unieważnienie | Trudne (bezstanowego JWT nie da się cofnąć) | Unieważnij token odświeżający; access ginie w ciągu minut |
| UX | Częste ponowne logowanie, jeśli krótki | Pozostajesz zalogowany bez ponownego wpisywania danych |
| Zasięg rażenia wycieku | Duży | Mały (access szybko wygasa) |

- **Jeden krótki token dostępu, bez refresh** → bezpiecznie, ale użytkownik jest wylogowywany co kilka minut. Fatalny UX.
- **Jeden długi token dostępu** → świetny UX, ale wyciekły token jest ważny długo i nie da się go łatwo unieważnić.
- **Access + refresh** → krótkie okno narażenia *oraz* długie sesje. Token odświeżający to jedyny długo żyjący sekret i mieszka w jednym bezpiecznym miejscu.

## Co umożliwia ten podział

- **Unieważnienie mimo bezstanowych tokenów dostępu.** Nie możesz unieważnić tokena dostępu JWT przed jego wygaśnięciem, ale *możesz* usunąć/odmówić tokena odświeżającego, więc sesja kończy się przy następnym odświeżeniu (w ciągu minut).
- **Rotacja tokenów odświeżających** — wydawaj nowy token odświeżający przy każdym użyciu i wykrywaj ponowne użycie starego (oznaka kradzieży), a następnie unieważniaj cały łańcuch.
- **Najmniejsze narażenie** — długo żyjący sekret (refresh) jest wysyłany do dokładnie jednego punktu końcowego, najlepiej przechowywany w ciasteczku `httpOnly`, poza zasięgiem XSS.

## Dlaczego to ważne

To standardowy nowoczesny projekt uwierzytelniania, a rekruterzy pytają o to, by sprawdzić, czy rozumiesz *dlaczego*, a nie tylko *jak*. Kluczowy wgląd to kompromis: bezstanowość i krótkie narażenie (access) kontra długie sesje i możliwość unieważnienia (refresh). Zrobienie tego źle — długo żyjący token dostępu, brak rotacji, refresh przechowywany w `localStorage` — zamienia pojedynczy wyciekły token w długotrwałe przejęcie konta. Nazwanie podziału i tego, co daje każdy token, jest tym, co powinien wiedzieć inżynier świadomy bezpieczeństwa.

	Jeden długo żyjący token dostępu	Access + refresh
Narażenie	Wysyłany przy każdym żądaniu, żyje długo → duże okno kradzieży	Access krótko żyjący; refresh rzadko wysyłany
Unieważnienie	Trudne (bezstanowego JWT nie da się cofnąć)	Unieważnij token odświeżający; access ginie w ciągu minut
UX	Częste ponowne logowanie, jeśli krótki	Pozostajesz zalogowany bez ponownego wpisywania danych
Zasięg rażenia wycieku	Duży	Mały (access szybko wygasa)

Dwie role

Dlaczego nie tylko jeden token?

Co umożliwia ten podział

Dlaczego to ważne

Powiązane pytania