Token nieprzezroczysty vs JWT

W Logto, jako kompleksowej platformie CIAM opartej na OIDC, tokeny autoryzacyjne odgrywają kluczową rolę w zabezpieczaniu interakcji użytkowników i zarządzaniu dostępem do zasobów. Wśród różnych typów tokenów używanych do autoryzacji, tokeny nieprzezroczyste i JWT (JSON Web Tokens) są najważniejsze.

Otrzymaliśmy kilka pytań od naszej społeczności, takie jak: Jakie są różnice między tokenem nieprzezroczystym a JWT? Dlaczego nie mogę zdekodować otrzymanego tokena dostępu i dlaczego długość tokena wydaje się krótka? Ten wpis na blogu ma na celu wyjaśnienie tych koncepcji i pomoc w zrozumieniu różnic między tokenami nieprzezroczystymi a JWT, ich zastosowań i dlaczego możesz napotkać różne zachowania podczas pracy z nimi.

Czym jest token nieprzezroczysty?#

Token nieprzezroczysty to rodzaj tokena dostępu, który, jak sama nazwa wskazuje, jest nieprzezroczysty lub nierozpoznawalny przez klienta lub jakąkolwiek stronę zewnętrzną. Oznacza to, że sam token nie zawiera żadnych czytelnych informacji o użytkowniku ani przyznanej autoryzacji.

Kiedy otrzymujesz token nieprzezroczysty, często wygląda on jak pozornie losowy ciąg znaków, a próba jego zdekodowania nie przyniesie żadnych znaczących danych.

Oto przykład tokena nieprzezroczystego:

Ponieważ rzeczywista zawartość tokena jest znana tylko przez serwer autoryzacyjny, który go wydał, aby zweryfikować token nieprzezroczysty, klient musi go odesłać z powrotem na serwer, który następnie weryfikuje jego autentyczność i określa powiązane uprawnienia. Takie podejście zapewnia, że poufne informacje pozostają ukryte, zapewniając dodatkową warstwę bezpieczeństwa, ale także wymaga dodatkowej komunikacji z serwerem w celu weryfikacji tokena.

Zalety:

• bezpieczeństwo: Tokeny nieprzezroczyste nie ujawniają żadnych poufnych informacji klientowi. Zawartość tokena jest znana tylko serwerowi autoryzacyjnemu.
• możliwość unieważnienia: Ponieważ token jest przechowywany na serwerze, a jedynym sposobem na jego weryfikację jest punkt introspekcji na serwerze autoryzacyjnym, serwer może łatwo unieważnić token w razie potrzeby i zapobiec nieautoryzowanemu dostępowi.
• mały rozmiar: Tokeny nieprzezroczyste są zazwyczaj krótsze niż JWT, co może być korzystne pod względem wydajności i przestrzeni pamięciowej.

Wady:

• stanowy: Tokeny nieprzezroczyste wymagają, aby serwer autoryzacyjny utrzymywał stan, aby zweryfikować token, co może wprowadzać dodatkową złożoność i obciążenie.
• wydajność: Konieczność dodatkowej komunikacji z serwerem w celu weryfikacji tokena może wpływać na wydajność, zwłaszcza w scenariuszach o dużym ruchu.

Czym jest JWT?#

W przeciwieństwie do tokenów nieprzezroczystych, JWT (JSON Web Token) to samodzielny, bezstanowy token, który przenosi informacje w ustrukturyzowanym i czytelnym formacie.

JWT składa się z trzech części: nagłówka, ładunku i podpisu, z których każda jest zakodowana w Base64URL.

Oto przykład JWT:

• nagłówek zawiera informacje o typie tokena i algorytmie używanym do podpisania. Na przykład: {"alg": "HS256", "typ": "JWT"}.
• Sekcja ładunku zawiera roszczenia — fragmenty informacji o użytkowniku lub autoryzacji — takie jak identyfikator użytkownika, czas wygaśnięcia i zakresy. Ponieważ te dane są zakodowane, a nie zaszyfrowane, każdy, kto ma token, może go zdekodować, aby zobaczyć roszczenia, chociaż nie można ich zmienić bez unieważnienia podpisu. Na podstawie specyfikacji i konfiguracji serwera autoryzacyjnego różne roszczenia mogą być uwzględnione w ładunku. To daje tokenowi jego samodzielny charakter. Na przykład: {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• podpis jest generowany przez połączenie nagłówka, ładunku i tajnego klucza za pomocą określonego algorytmu. Podpis ten jest używany do weryfikacji integralności tokena i zapewnienia, że nie został zmanipulowany.

JWT są popularnie używane, ponieważ mogą być weryfikowane lokalnie przez klienta lub dowolną usługę, bez konieczności interakcji z serwerem autoryzacyjnym. To sprawia, że JWT są szczególnie efektywne dla systemów rozproszonych, gdzie wiele usług może potrzebować niezależnie zweryfikować autentyczność tokena.

Jednak to wygodne zastosowanie wiąże się również z odpowiedzialnością zapewnienia, że roszczenia zawarte w tokenie nie są nadmiernie eksponowane, ponieważ są widoczne dla każdego, kto ma dostęp do tokena. Ponadto, JWT są zazwyczaj krótkotrwałe, a czas wygaśnięcia jest uwzględniony w roszczeniach tokena, aby zapewnić, że token nie jest ważny bez końca.

Zalety:

• bezstanowy: JWT są samodzielne i nie wymagają stanu po stronie serwera do weryfikacji.
• kompatybilność między usługami: JWT można łatwo udostępniać i weryfikować w różnych usługach, co czyni je idealnymi dla systemów rozproszonych.
• elastyczność: Ładunek JWT może zawierać niestandardowe roszczenia, umożliwiając elastyczną autoryzację i udostępnianie informacji.
• standard: Tokeny JWT podążają za dobrze określonym standardem (RFC 7519), co czyni je szeroko wspieranymi i interoperacyjnymi.

Wady:

• narażenie: Roszczenia w JWT są widoczne dla każdego, kto ma dostęp do tokena, dlatego poufne informacje nie powinny być zawarte w ładunku.
• duży rozmiar: JWT mogą być większe niż tokeny nieprzezroczyste ze względu na dodatkowe informacje, które przenoszą, co może wpłynąć na wydajność i miejsce na dane. Roszczenia w tokenach JWT powinny być ograniczone do minimum, aby zmniejszyć rozmiar tokena.
• złożoność unieważnienia: Ponieważ JWT są bezstanowe, są zazwyczaj ważne przez krótki okres czasu i nie ma wbudowanego mechanizmu do unieważniania tokenów przed ich wygaśnięciem, co oznacza, że skompromitowany token może pozostawać ważny do czasu jego wygaśnięcia.

Weryfikacja tokena dostępu nieprzezroczystego#

Token dostępu nieprzezroczystego jest weryfikowany przez odesłanie go z powrotem do serwera autoryzacyjnego w celu jego weryfikacji. Serwer autoryzacyjny utrzymuje stan wydanych tokenów i może określić ważność tokena na podstawie swojej wewnętrznej pamięci.

1. Klient żąda tokena dostępu od serwera autoryzacyjnego.
2. Serwer autoryzacyjny wydaje token nieprzezroczysty.
3. Klient przesyła żądanie dostępu do zasobu z tokenem nieprzezroczystym w nagłówku.
4. Dostawca zasobów przesyła żądanie introspekcji tokena do serwera autoryzacyjnego w celu zweryfikowania tokena.
5. Serwer autoryzacyjny odpowiada informacjami o tokenie.

Weryfikacja tokena dostępu JWT (offline)#

Token dostępu JWT może być weryfikowany offline przez klienta lub dowolną usługę, która ma dostęp do klucza publicznego tokena.

0. Dostawca zasobów pobiera klucz publiczny serwera autoryzacyjnego z odkrywczego punktu końcowego OIDC. Klucz publiczny jest używany do weryfikacji podpisu tokena i zapewnienia jego integralności.
1. Klient żąda tokena dostępu od serwera autoryzacyjnego.
2. Serwer autoryzacyjny wydaje token JWT.
3. Klient przesyła żądanie dostępu do zasobu z tokenem JWT w nagłówku.
4. Dostawca zasobów dekoduje i weryfikuje token JWT za pomocą klucza publicznego uzyskanego od serwera autoryzacyjnego.
5. Dostawca zasobów przyznaje dostęp na podstawie ważności tokena.

Zastosowania w OIDC#

W kontekście OIDC (OpenID Connect), tokeny nieprzezroczyste i JWT służą różnym celom i są używane w odrębnych scenariuszach.

Tokeny nieprzezroczyste#

1. Pobieranie profilu użytkownika:

Domyślnie, gdy klient żąda tokena dostępu bez określenia zasobu i obejmuje zakres openid, serwer autoryzacyjny wydaje nieprzezroczysty token dostępu. Ten token jest głównie używany do pobierania informacji o profilu użytkownika z punktu końcowego OIDC /oidc/userinfo. Po otrzymaniu żądania z nieprzezroczystym tokenem dostępu, serwer autoryzacyjny sprawdza swoje wewnętrzne zasoby, aby pobrać powiązane informacje o autoryzacji i weryfikuje ważność tokena przed odpowiedzią z danymi profilu użytkownika.

2. Wymiana tokena odświeżania:

Tokeny odświeżania są zaprojektowane do wymiany tylko między klientem a serwerem autoryzacyjnym, bez konieczności udostępniania ich dostawcom zasobów. W związku z tym tokeny odświeżania są zazwyczaj wydawane jako tokeny nieprzezroczyste. Kiedy wygasa aktualny token dostępu, klient może użyć nieprzezroczystego tokena odświeżania, aby uzyskać nowy token dostępu, zapewniając ciągły dostęp bez ponownego uwierzytelniania użytkownika.

JWT#

1. Token identyfikacyjny:

W OIDC, token identyfikacyjny to JWT, który zawiera informacje o użytkowniku i jest używany do uwierzytelniania użytkownika. Zazwyczaj wydawany razem z tokenem dostępu, token identyfikacyjny pozwala klientowi zweryfikować tożsamość użytkownika. Na przykład:

Klient może zweryfikować token identyfikacyjny, aby upewnić się co do tożsamości użytkownika i wyodrębnić informacje o użytkowniku do celów personalizacji lub autoryzacji. Token identyfikacyjny jest do jednorazowego użytku i nie powinien być używany do autoryzacji dostępu do zasobów API.

2. Dostęp do zasobów API:

Gdy klient żąda tokena dostępu z określonym wskaźnikiem zasobu, serwer autoryzacyjny wydaje token dostępu JWT przeznaczony do uzyskiwania dostępu do tego zasobu. JWT zawiera roszczenia, które dostawca zasobów może użyć do autoryzacji dostępu klienta. Na przykład:

Dostawca zasobów może zweryfikować żądanie poprzez sprawdzenie roszczeń:

• iss: Potwierdza, że token został wydany przez zaufany serwer autoryzacyjny.
• sub: Identyfikuje użytkownika związanego z tokenem.
• aud: Upewnia się, że token jest przeznaczony dla konkretnego zasobu.
• scope: Weryfikuje uprawnienia przyznane użytkownikowi.

Podsumowanie#

Podsumowując, tokeny nieprzezroczyste i JWT służą różnym celom w systemach opartych na OIDC, z tokenami nieprzezroczystymi zapewniającymi bezpieczne i stanowe podejście do autoryzacji, a JWT oferującymi samodzielną i bezstanową alternatywę. Zrozumienie różnic między tymi typami tokenów i ich zastosowaniami jest kluczowe dla zaprojektowania bezpiecznych i efektywnych mechanizmów uwierzytelniania i autoryzacji w twoich aplikacjach.

Odkryj więcej funkcji tokenów dostępu w Logto:

• Używaj RBAC do ochrony swojego API
• Token dostępu organizacji
• Niestandardowe roszczenia JWT