Token nieprzezroczysty vs JWT
Zrozum różnice między tokenami nieprzezroczystymi a JWT, ich zastosowania oraz jak są weryfikowane w systemach opartych na OIDC.
Zrozum różnice między tokenami nieprzezroczystymi a JWT, ich zastosowania oraz jak są weryfikowane w systemach opartych na OIDC.
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.
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:
Wady:
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:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cnagłówek zawiera informacje o typie tokena i algorytmie używanym do podpisania. Na przykład: {"alg": "HS256", "typ": "JWT"}.ł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:
Wady:
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.
Token dostępu JWT może być weryfikowany offline przez klienta lub dowolną usługę, która ma dostęp do klucza publicznego tokena.
W kontekście OIDC (OpenID Connect), tokeny nieprzezroczyste i JWT służą różnym celom i są używane w odrębnych scenariuszach.
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.
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.
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.
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.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: