Token to ciąg znaków, który potwierdza Twoją tożsamość albo uprawnienia, gdy aplikacja gada z API lub innym systemem. Zamiast wysyłać login i hasło przy każdym żądaniu, raz się uwierzytelniasz, dostajesz token i potem dołączasz go do kolejnych zapytań. Serwer patrzy na token i decyduje: wpuścić czy odprawić z kwitkiem.
Najczęściej token wędruje w nagłówku HTTP Authorization: Bearer . Serwer go odczytuje, sprawdza ważność i odczytuje, kim jesteś oraz co Ci wolno. Tokeny zwykle mają termin ważności (czasem kilka minut), więc nawet gdy wyciekną, okno na nadużycie jest ograniczone. To duża przewaga nad hasłem, które jest ważne, dopóki go nie zmienisz.
Skąd się biorą i jak wyglądają
Popularny format to JWT (JSON Web Token) — trzy części oddzielone kropkami: nagłówek, payload z danymi (np. sub, exp) i podpis. Podpis pilnuje, żeby nikt nie przerobił treści. Co ważne: payload jest tylko zakodowany w Base64, nie zaszyfrowany — każdy go odczyta, więc nie wpychaj tam haseł ani numeru karty.
W praktyce wygląda to tak. Logujesz się do API GitHuba i zamiast hasła używasz Personal Access Token:
curl -H "Authorization: Bearer ghp_xxxxxxxx" https://api.github.com/user
W modelu OAuth 2.0 (logowanie przez Google czy Facebook) dostajesz access token do bieżących żądań oraz refresh token, którym wymieniasz wygasły access token na nowy, bez ponownego logowania.
Na co uważać
- Token to sekret. Kto go ma, ten jest Tobą. Nie wrzucaj go do repo, logów ani frontendowego kodu widocznego w przeglądarce.
- Tylko HTTPS. Po HTTP token leci otwartym tekstem i każdy w sieci go przechwyci.
- Mit „JWT się szyfruje”. Nie — domyślnie tylko podpisuje. Nie traktuj payloadu jako tajnego.
- Krótki czas życia + refresh. Lepszy niż jeden wieczny token, którego nie da się unieważnić.
- Token to nie API key. Klucz API zwykle identyfikuje aplikację i bywa długowieczny; token częściej dotyczy konkretnego użytkownika i sesji.
Pojęcia powiązane: JWT, OAuth 2.0, API key, Bearer authentication, sesja, refresh token, autentykacja i autoryzacja, CSRF token.