JWT vs OAuth: Kluczowe różnice, jak współpracują i najlepsze praktyki

Jeśli dopiero zaczynasz przygodę z uwierzytelnianiem i tworzysz aplikację obsługującą logowanie, płatności lub dane użytkownika, zapewne spotkałeś się z pojęciami JWT oraz OAuth. Mogą brzmieć, jakby były zarezerwowane tylko dla programistów back-endu, ale wcale nie są zastrzeżone tylko dla specjalistów ds. bezpieczeństwa.

W epoce API, integracji z firmami trzecimi oraz nowych technologii takich jak AI, MCP i systemy oparte na agentach, te dwa pojęcia mają bezpośredni wpływ na użyteczność, bezpieczeństwo i rozwój twojego produktu. Zrozumienie podstaw oznacza, że możesz:

• Projektować funkcje bezpieczne już od pierwszych kroków
• Komunikować się skutecznie ze swoim zespołem inżynierskim
• Podejmować lepsze decyzje dotyczące uwierzytelniania i przepływu użytkowników
• Unikać kosztownych błędów bezpieczeństwa, które mogą podważyć zaufanie użytkowników

Dla przykładu, w najnowszej specyfikacji MCP system autoryzacji oparty jest na sprawdzonych standardach:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Dlaczego to ważne#

Nawet jeśli nigdy nie piszesz kodu back-endowego:

• Programiści dowiadują się, jak zabezpieczać API, zarządzać sesjami i integrować się z zewnętrznymi usługami.
• Product managerowie zyskują słownictwo umożliwiające omawianie procesów logowania, integracji i zgodności z zespołami i partnerami.
• Założyciele i małe zespoły unikają budowania kruchego systemu logowania, który może zawieść przy integracjach lub narazić na wycieki danych.

JWT vs OAuth: Dwa podstawowe pojęcia#

JWT (JSON Web Token) i OAuth (Open Authorization) często używane są razem, ale pełnią różne funkcje.

Możesz to sobie wyobrazić tak:

• OAuth to sposób na przekazanie komuś kluczy, ale tylko do tych pomieszczeń, do których ma dostęp.
• JWT to dowód tożsamości, który nosi ze sobą, pokazując kim jest i do czego ma uprawnienia.

W kolejnej sekcji rozłożymy oba te rozwiązania na czynniki pierwsze, by łatwo zobaczyć ich różnice oraz to, jak się uzupełniają.

Czym jest OAuth 2.0?#

OAuth 2.0 to szeroko stosowane ramy autoryzacji, umożliwiające aplikacji (klientowi) dostęp do zasobów użytkownika z ograniczonymi uprawnieniami, bez konieczności udostępniania danych uwierzytelniających (np. haseł).

Podstawowe role w OAuth#

• Klient: Aplikacja żądająca dostępu.
• Właściciel zasobu: Najczęściej użytkownik wyrażający na to zgodę.
• Serwer autoryzacyjny: Wydaje tokeny dostępu po autoryzacji.
• Serwer zasobów: Przechowuje chronione zasoby i waliduje tokeny.

Najczęstsze typy grantów OAuth (Przepływy)#

• Authorization Code Grant: Najbezpieczniejszy i zalecany, zwłaszcza z PKCE dla aplikacji przeglądarkowych, SPA i mobilnych.
• Implicit Grant: Obecnie odradzany w OAuth 2.1 ze względu na kwestie bezpieczeństwa.
• Resource Owner Password Credentials (ROPC): Wymiana loginu i hasła na tokeny; mniej bezpieczna.
• Client Credentials Grant: Dla komunikacji serwer-serwer lub maszyna-maszyna.
• Device Flow: Dla urządzeń bez klawiatury (np. smart TV), gdzie użytkownik autoryzuje się z innego urządzenia.

Czym jest JWT (JSON Web Token)?#

JWT to otwarty standard (RFC 7519) umożliwiający bezpieczne przekazywanie roszczeń (claims) między dwoma stronami w kompaktowej, bezpiecznej dla URL formie.

Struktura JWT#

JWT składa się z trzech części zakodowanych w base64url, oddzielonych kropkami (.):

1. Nagłówek: Określa algorytm (np. HS256, RS256) i typ tokena (JWT).
2. Ładunek: Zawiera roszczenia (claims), takie jak:
   • iss (issuer – wystawca)
   • sub (subject – np. ID użytkownika)
   • aud (audience – docelowy odbiorca)
   • exp (expiration time – data ważności)
   • Roszczenia niestandardowe w razie potrzeby
3. Podpis – Potwierdza, że token nie został zmodyfikowany.

Przykład:

Przykład JWT#

Oto przykład typowego JWT w zakodowanej formie oraz jego struktura po dekodowaniu, by zobaczyć, co oznacza każda część.

Zakodowany JWT (Base64URL)

Składa się z trzech części oddzielonych kropkami: header.payload.signature

Struktura po dekodowaniu

• Nagłówek

• Ładunek

Ładunek zawiera roszczenia (claims)

• Podpis

Podpis zapewnia, że token nie został sfałszowany.

Kluczowe cechy#

• Samowystarczalny: Wszystkie potrzebne informacje są wewnątrz tokena.
• Bezstanowy: Nie wymaga przechowywania sesji po stronie serwera.
• Podpisany (i opcjonalnie zaszyfrowany), by zapewnić autentyczność.

JWT vs OAuth: Główne różnice#

Krótko mówiąc:

• JWT to pojemnik: jak paszport z danymi tożsamości.
• OAuth to system: jak kontrola graniczna, decydująca, kto dostaje paszport i do czego ma dostęp.

Kiedy używać samego JWT#

Stosuj JWT samodzielnie, gdy:

• Autoryzacja w jednym systemie, gdzie twoja aplikacja wystawia i sprawdza tokeny bez udziału zewnętrznego dostawcy tożsamości.
• Bezstanowe zarządzanie sesjami, by potwierdzić tożsamość użytkownika bez przechowywania danych sesji na serwerze.
• Proste uwierzytelnianie API dla wewnętrznych API, wymagających wyłącznie podstawowej weryfikacji uprawnień bez złożonych zgód.
• Walidacja skupiona na wydajności, gdy serwery zasobów mogą sprawdzać tokeny lokalnie bez kontaktu z serwerem autoryzacyjnym.

Przykład:

Single-page app oraz posiadane przez ciebie back-endowe API. API wydaje JWT zawierające sub (ID użytkownika), role i exp (czas wygaśnięcia).

Kiedy używać samego OAuth#

Stosuj OAuth bez JWT, gdy:

• Nie potrzebujesz samowystarczalnych tokenów, a wystarczą ci tokeny nieprzezroczyste (opaque), które wymagają odwołania do serwera.
• Chcesz, by serwer zasobów zawsze sprawdzał uprawnienia na serwerze autoryzacyjnym przed przyznaniem dostępu.
• Pracujesz w środowisku starszym lub regulowanym, gdzie JWT nie jest akceptowany.
• Głównym celem jest delegowana autoryzacja, czyli bezpieczne przyznawanie ograniczonego dostępu aplikacjom trzecim.

Przykład:

API wydaje nieprzezroczyste tokeny dostępu i weryfikuje każde żądanie, odwołując się do serwera autoryzacyjnego.

Kiedy używać zarówno JWT, jak i OAuth#

Stosuj je razem, gdy:

• Masz wiele usług lub API i chcesz wykorzystać OAuth do bezpiecznego nadawania uprawnień oraz JWT jako formę weryfikowalnych tokenów.
• Umożliwiasz logowanie przez zewnętrznych dostawców typu „Zaloguj przez Google”, gdzie OAuth obsługuje zgodę, a JWT przenosi token dostępu lub tożsamości.
• Korzystasz z architektury mikroserwisów, w której każdy serwis może lokalnie sprawdzić JWT.
• Potrzebujesz skalowalności dzięki delegacji OAuth i bezstanowej weryfikacji JWT.

Przykład:

Twoja aplikacja umożliwia logowanie przez Google. OAuth zarządza autoryzacją, Google wydaje JWT jako token dostępu, a twoje API sprawdza go lokalnie przed udostępnieniem danych.

Jak JWT i OAuth współpracują#

W nowoczesnych systemach uwierzytelniania/autoryzacji:

1. OAuth obsługuje proces przyznawania dostępu.
2. Serwer autoryzacyjny wystawia token dostępu: często jest to JWT.
3. JWT jest wysyłane z żądaniami do API, by potwierdzić tożsamość i uprawnienia.

Specjalne tokeny w OAuth#

• ID token: Używany w OpenID Connect do potwierdzania tożsamości użytkownika; zawsze JWT.
• Access token: Może być JWT lub tokenem nieprzezroczystym (opaque).

Najlepsze praktyki stosowania JWT i OAuth#

• Korzystaj z HTTPS, by chronić tokeny w transmisji.
• Ustawiaj krótkie czasy wygaśnięcia dla JWT; do długich sesji używaj refresh tokenów.
  • https://auth.wiki/offline-access.
• Waliduj podpis zanim zaufasz roszczeniom zawartym w tokenie.
• Sprawdź roszczenie aud, by upewnić się, że token jest przeznaczony dla twojej aplikacji.
• Unikaj przechowywania tokenów w localStorage jeśli grozi XSS; preferuj bezpieczne ciasteczka.

Podsumowanie#

• OAuth 2.0 określa jak uzyskiwać i wykorzystywać tokeny.
• JWT opisuje jak wygląda token i w jaki sposób przenosi informacje.
• Są komplementarne, a nie zamienne.

Większość nowoczesnych API stosuje OAuth dla logiki autoryzacji i JWT jako reprezentacji tokenu. Znając oba, łatwiej zaprojektujesz bezpieczne, skalowalne systemy uwierzytelniania.