JSON Web Token (JWT)
JWT to poświadczenie, które aplikacja wydaje po zalogowaniu. Co sprawdza jego podpis, jakie są pułapki i jak postępować.
W 30 sekund
- Gdzie to się zdarza
- W platformie tożsamości Microsoft, która uwierzytelnia użytkowników i dostarcza tokeny dostępu, odświeżania i tożsamości1.
- Czego chce atakujący
- Ukraść ważny token, by działać z uprawnieniami jego właściciela, bez znajomości hasła2.
- Odruch
- Nigdy nie wysyłać ani nie publikować tokenu ani adresu, który go zawiera, wylogowywać się po zakończeniu pracy i zgłaszać każde nietypowe zachowanie.
- Jeśli już się stało
- Wylogować się, a następnie powiadomić dział IT. OWASP przypomina, że usunięcie ciasteczka nie wystarcza: „deleting a cookie alone does not invalidate a stolen copy of the session ID”, a unieważnienie po stronie serwera jest konieczne6.
O co chodzi
Po zalogowaniu do aplikacji firmowej otrzymuje Pan/Pani od niej cyfrowe poświadczenie, które przeglądarka lub aplikacja przedstawia następnie przy każdym żądaniu. W Microsoft poświadczenie to ma postać JSON Web Token, czyli JWT, zawierającego „claims”, czyli oświadczenia o użytkowniku lub aplikacji1.
JWT można zdekodować, na przykład za pomocą witryny jwt.ms, a jego podpis służy do sprawdzenia autentyczności tokenu3. Ta fiszka opisuje postępowanie pracownika i osoby odpowiedzialnej za system.
Pytania wprost
Czym jest JWT?
JWT składa się z trzech segmentów oddzielonych kropką: nagłówka, treści i podpisu3. Treść zawiera claims. Podpis służy do oceny autentyczności tokenu3.
Czy podpis uniemożliwia odczytanie tokenu?
Podpis służy do sprawdzenia autentyczności tokenu. Microsoft wskazuje, że programiści mogą zdekodować JWT za pomocą witryny takiej jak jwt.ms, w celu walidacji i debugowania3. Token jest wrażliwy i stwarza ryzyko dla bezpieczeństwa, jeśli jest nieprawidłowo obsługiwany3.
Czy skradziony token naprawdę pozwala działać w moim imieniu?
Tak. MITRE opisuje przeciwników, którzy używają skradzionych tokenów dostępu, by obejść zwykły proces uwierzytelniania i uzyskać dostęp do kont, informacji lub usług. Tokeny te są używane zamiast danych logowania2.
Czy skradziony token długo pozostaje ważny?
To zależy od jego czasu życia. W przypadku tokenów dostępu Microsoft domyślny czas życia to losowa wartość z przedziału od 60 do 90 minut, średnio 75 minut3. Dzierżawy bez dostępu warunkowego mają domyślny czas życia dwóch godzin dla klientów takich jak Microsoft Teams i Microsoft 3653. MITRE zauważa jednak, że przeciwnik może czasem ukraść także token odświeżania, który pozwala mu uzyskiwać nowe tokeny dostępu bez angażowania użytkownika4.
1Jak to działa1 min
Serwer autoryzacji podpisuje token kluczem prywatnym i publikuje odpowiadający mu klucz publiczny. Aby zweryfikować token, aplikacja sprawdza podpis tym kluczem publicznym1. Nagłówek JWT wskazuje algorytm podpisu (claim alg) i klucz publiczny, którego należy użyć (claim kid)3. Microsoft Entra ID wydaje tokeny podpisane standardowymi algorytmami asymetrycznymi, takimi jak RS2563.
Token dostępu jest przekazywany do API jako token „bearer” w nagłówku Authorization1. Ponieważ tokeny są ważne przez ograniczony czas, serwer często dostarcza parę: token dostępu i token odświeżania, który służy do odnowienia pierwszego, gdy zbliża się jego wygaśnięcie1. Token odświeżania daje nowy token dostępu tylko wtedy, gdy użytkownik nadal ma uprawnienia1.
W przypadku OpenID Connect ID Token jest podpisanym JWT, który pozwala aplikacji zweryfikować tożsamość użytkownika5.
2Co należy robić1 min
Jako pracownik:
- Proszę nigdy nie wysyłać tokenu ani adresu internetowego, który go zawiera, w wiadomości, zgłoszeniu ani na forum. Identyfikatory sesji umieszczone w adresie mogą trafić do linków, dzienników, historii przeglądarki, zakładek, nagłówka Referer lub wyszukiwarek6.
- Proszę się wylogować po zakończeniu pracy. Aplikacja powinna oferować widoczny i dostępny przycisk wylogowania, aby użytkownik mógł zamknąć sesję w dowolnej chwili6.
- Proszę nie polegać na zamknięciu przeglądarki: nie pozwala ono niezawodnie wymusić wylogowania, zwłaszcza na urządzeniach mobilnych6.
- Proszę zgłaszać nietypowe zachowanie (nieoczekiwane wylogowania, czynności, których Pan/Pani nie wykonał(a), prośba o autoryzację nieznanej aplikacji). MITRE opisuje atakujących, którzy doprowadzają do przyznania dostępu złośliwej aplikacji, wysyłając ukierunkowany link phishingowy4.
Jako osoba odpowiedzialna, do wymagania od zespołów i dostawców:
- Walidacji podpisu i wystawcy przez aplikację, która otrzymuje token, z wartościami opublikowanymi w dokumencie wykrywania OpenID3.
- Kontroli odbiorcy: API powinno akceptować tylko tokeny, w których claim
audmu odpowiada. Przyjęcie tokenu przeznaczonego dla innego zasobu jest przykładem problemu „confused deputy”3. - Sprawdzonych bibliotek zamiast własnego kodu. Microsoft zaleca swoje biblioteki MSAL, które obsługują uzyskiwanie, odświeżanie i walidację tokenów1.
- Ograniczonego czasu trwania sesji. OWASP podaje jako typowe zakresy limitu bezczynności 2 do 5 minut dla aplikacji o wysokiej wartości i 15 do 30 minut dla aplikacji o niskim ryzyku, a także zaleca limit bezwzględny niezależnie od aktywności6.
- Ostrożnego przechowywania po stronie przeglądarki (zob. następna sekcja).
3Pułapki2 min
MITRE wskazuje, że skradzione tokeny są „used in lieu of login credentials”, czyli używane zamiast danych logowania2. MITRE zauważa, że ciasteczka sesji mogą omijać niektóre protokoły uwierzytelniania wieloskładnikowego7.
W źródłach powtarza się kilka błędów implementacji.
- Przechowywanie w przeglądarce. OWASP odradza przechowywanie tokenów uwierzytelniania, identyfikatorów sesji, JWT lub tokenów odświeżania w localStorage lub sessionStorage: te przestrzenie są dostępne dla każdego kodu JavaScript uruchomionego w danym źródle, więc jedna luka XSS ujawnia wszystkie tokeny6. OWASP woli ciasteczka HttpOnly, Secure i SameSite=Strict albo model typu Backend-for-Frontend6.
- Token w adresie. Identyfikator przekazany w adresie URL może wyciec i ułatwić inne ataki, takie jak session fixation6.
- Walidacja w niewłaściwym miejscu. Według Microsoft klient nie powinien próbować walidować tokenu dostępu: to zadanie API, a klient traktuje go jak nieprzezroczysty ciąg znaków3.
- Zaufanie do treści bez sprawdzenia podpisu. Aplikacja, która ma zwalidować token, zaczyna od sprawdzenia podpisu i wystawcy3.
- Tokeny wykradzione z infrastruktury. W środowiskach Kubernetes lub w potokach ciągłej integracji i wdrażania tokeny API mogą zostać skradzione, jeśli kontener lub potok zostanie przejęty4.
- Kradzież sesji przez złośliwy skrypt lub proxy phishingowe. MITRE wymienia złośliwe oprogramowanie atakujące ciasteczka przeglądarki oraz darmowe narzędzia, takie jak Evilginx2 i Muraena, które zbierają ciasteczka przez złośliwe proxy7.
Cytowane tu źródła nie opisują szczegółowo innych często wymienianych błędów projektowych, takich jak algorytm „none”, pomylenie kluczy czy słabe sekrety. Zespoły programistyczne powinny to sprawdzić według własnych dokumentów referencyjnych.
Karta
- Identyfikator
- CP-195
- Skrzydło
- 3. Protokoły i obrona
- Kompetencja Brain
- Kontrolować dostęp (control_access)
- Odruch Brain
- cr-027
- Schemat
- G3 · Przekrój anatomiczny
- Języki
- de, en, es, fr, it, nl, pl, pt
- Źródła
- Źródła sprawdzone 3 listopada 2026: 7
ŹródłaŹródła: 7
- Microsoft, „Tokens and claims overview - Microsoft identity platform”, 21 marca 2025. https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens (dostęp 3 listopada 2026)
- MITRE ATT&CK, „Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1550/001/ (dostęp 3 listopada 2026)
- Microsoft, „Access tokens in the Microsoft identity platform - Microsoft identity platform”, 14 maja 2025. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (dostęp 3 listopada 2026)
- MITRE ATT&CK, „Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1528/ (dostęp 3 listopada 2026)
- OWASP, „Authentication - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html (dostęp 3 listopada 2026)
- OWASP, „Session Management - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (dostęp 3 listopada 2026)
- MITRE ATT&CK, „Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1539/ (dostęp 3 listopada 2026)
Zacytuj ten artykuł
Brain, „JSON Web Token (JWT)”, Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp195_pl_2026,
author = {Brain},
title = {JSON Web Token (JWT)},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/pl/articles/jwt-json-web-token-podpis-puapki/},
note = {CC BY 4.0}
}