Dodaj niestandardowe roszczenia do tokenów dostępu JWT z Logto, aby zwiększyć swoje uprawnienia

W poprzednich artykułach wspomnieliśmy, że coraz więcej systemów używa tokenów dostępu w formacie JWT do uwierzytelniania użytkownika i kontroli dostępu. Jednym z ważnych powodów tego jest to, że JWT może zawierać pewne przydatne informacje, takie jak role użytkownika i uprawnienia. Te informacje mogą pomóc w przekazywaniu informacji o tożsamości użytkownika między serwerem a klientem, co pozwala na uwierzytelnianie użytkowników i kontrolę dostępu.

Zazwyczaj informacje zawarte w JWT są określane przez serwer uwierzytelniający. Zgodnie z protokołem OAuth 2.0, JWT zazwyczaj zawiera pola takie jak sub (podmiot), aud (odbiorca) i exp (czas wygaśnięcia), które są powszechnie nazywane roszczeniami. Te roszczenia mogą pomóc w weryfikacji ważności tokenu dostępu.

Jednak istnieje wiele scenariuszy, w których JWT jest używany do weryfikacji, a wspólne roszczenia JWT mogą nie spełniać potrzeb użytkowników. Często myśli się o tym, że skoro JWT może zawierać pewne informacje, czy możemy dodać do niego dodatkowe informacje, aby ułatwić uprawnienia?

Odpowiedź brzmi TAK, możemy dodać niestandardowe roszczenia do JWT, takie jak zakres bieżącego użytkownika i poziom subskrypcji. W ten sposób możemy przekazywać informacje o tożsamości użytkownika między klientem a serwerem (tutaj chodzi o serwera, który świadczy różne usługi, także nazywanego dostawcą usług), aby osiągnąć uwierzytelnianie użytkownika i kontrolę dostępu.

Dla standardowych roszczeń JWT zobacz RFC7519. Logto, jako rozwiązanie tożsamościowe wspierające zarówno uwierzytelnianie, jak i autoryzację, rozszerzyło roszczenia związane z zasobami i zakresem na tej podstawie, aby wspierać standardowe RBAC. Chociaż implementacja RBAC w Logto jest standardowa, nie jest ona wystarczająco prosta i elastyczna, aby pasować do wszystkich przypadków użycia.

Na tej podstawie Logto wprowadziło nową funkcję dostosowywania roszczeń JWT, która umożliwia użytkownikom dostosowanie dodatkowych roszczeń JWT, aby uwierzytelnianie użytkowników i kontrola dostępu mogły być realizowane bardziej elastycznie.

Jak działają niestandardowe roszczenia JWT w Logto?#

Możesz przejść do strony listingu niestandardowych JWT, klikając przycisk „JWT claims” na pasku bocznym.

Zacznijmy od dodawania niestandardowych roszczeń dla użytkowników końcowych.

W edytorze po lewej stronie możesz dostosować swoją funkcję getCustomJwtClaims. Ta metoda ma trzy parametry wejściowe: token, data i envVariables.

• token to surowy ładunek tokenu dostępu uzyskany na podstawie bieżących poświadczeń użytkownika końcowego oraz konfiguracji systemu, a także informacji związanych z dostępem użytkownika w Logto
• data to wszystkie informacje o użytkowniku w Logto, w tym wszystkie role użytkownika, tożsamości logowania społecznościowego, tożsamości SSO, członkostwo w organizacjach itd.
• envVariables to zmienne środowiskowe, które skonfigurowałeś w Logto dla bieżącego scenariusza użycia tokenu dostępu użytkownika końcowego, jak np. klucze API potrzebnych zewnętrznych API itd.

Karty po prawej stronie mogą być rozszerzone, aby pokazać wprowadzenie odpowiednich parametrów, a także możesz tutaj ustawić zmienne środowiskowe dla bieżącego scenariusza.

Po przeczytaniu wprowadzeń wszystkich kart po prawej stronie możesz przełączyć się na tryb testowy, gdzie możesz edytować dane testowe i wykorzystać edytowane dane testowe do sprawdzenia, czy zachowanie skryptu, które napisałeś w edytorze kodu po lewej stronie, spełnia twoje oczekiwania.

To jest diagram sekwencji pokazujący proces wykonania funkcji getCustomJwtClaims, gdy użytkownik końcowy inicjuje żądanie uwierzytelnienia do Logto i ostatecznie uzyskuje token dostępu w formacie JWT zwrócony przez Logto.

Jeśli funkcja Custom JWT nie jest włączona, krok 3 na rysunku zostanie pominięty, a krok 4 zostanie wykonany zaraz po zakończeniu kroku 2. W tym momencie Logto zakłada, że wartość zwracana przez getCustomJwtClaims to pusty obiekt, a następnie przechodzi do kolejnych kroków.

Zwiększ swoje uprawnienia za pomocą niestandardowych roszczeń JWT: praktyczny przykład#

W poprzedniej sekcji wprowadziliśmy zasadę działania niestandardowego JWT w Logto. W tej części pokażemy, jak korzystać z niestandardowych roszczeń JWT w Logto, aby poprawić elastyczność uprawnień oraz wydajność dostawcy usług na przykładzie z rzeczywistości.

Konfiguracja scenariusza#

Zespół Johna opracował aplikację AI Assistant, która umożliwia użytkownikom rozmowy z robotami AI w celu uzyskania różnych usług.

Usługi robotów AI są podzielone na usługi bezpłatne i płatne. Usługi bezpłatne obejmują rekomendacje dotyczące specjalnych taryf lotniczych, natomiast usługi płatne obejmują prognozy giełdowe.

Aplikacja AI Assistant używa Logto do zarządzania wszystkimi użytkownikami, którzy są podzieleni na trzy typy: użytkownicy bezpłatni, użytkownicy przedpłatni i użytkownicy premium. Użytkownicy bezpłatni mogą korzystać tylko z bezpłatnych usług, użytkownicy przedpłatni mogą korzystać ze wszystkich usług (płatnych według użycia), a użytkownicy premium mogą korzystać ze wszystkich usług (ale mają ograniczenia liczby połączeń, aby zapobiec złośliwemu wykorzystaniu).

Dodatkowo, aplikacja AI Assistant używa Stripe do zarządzania płatnościami użytkowników i ma własny serwis logowania, aby rejestrować logi operacji użytkowników.

Konfiguracja Logto#

Najpierw tworzymy zasoby API dla usługi aplikacji AI Assistant i tworzymy dwa zakresy, recommend:flight i predict:stock.

Następnie tworzymy dwa roles, free-user i paid-user, i przypisujemy odpowiednie zakresy:

• Przypisz zakres recommend:flight do roli free-user.
• Przypisz zarówno zakres recommend:flight, jak i predict:stock do roli paid-user.

Na koniec tworzymy trzech użytkowników, free-user, prepaid-user i premium-user, i przypisujemy odpowiednie role:

• Przypisz rolę free-user do użytkownika free-user.
• Przypisz rolę paid-user do użytkowników prepaid-user i premium-user.

Jak pokazano na poniższym rysunku, aby wdrożyć informacje potrzebne do uprawnień w opisanym powyżej scenariuszu, chcemy uwzględnić informacje roles, balance i numOfCallsToday obecnie zalogowanego użytkownika w JWT. Podczas weryfikacji tokenu dostępu w aplikacji AI Assistant, te informacje mogą być wykorzystane do szybkiego przeprowadzenia weryfikacji uprawnień.

Po skonfigurowaniu envVariables, implementujemy funkcję getCustomJwtClaims i klikamy przycisk „Uruchom test”, aby zobaczyć rezultat dodatkowych roszczeń JWT opartych na bieżących danych testowych.

Ponieważ nie skonfigurowaliśmy danych testowych dla data.user.roles, rola przedstawiona w wyniku to pusta tablica.

Sprawdź, czy funkcja niestandardowego JWT zostaje uruchomiona#

Zgodnie z powyższą konfiguracją Logto, uzyskaliśmy odpowiednie wyniki w teście. Następnie użyjemy przykładowej aplikacji dostarczonej przez Logto, aby sprawdzić, czy nasze niestandardowe JWT jest skuteczne. Znajdź SDK, z którą jesteś zaznajomiony w SDK Logto i wdroż przykładową aplikację zgodnie z dokumentacją oraz odpowiednim repozytorium GitHub.

Na podstawie konfiguracji opisanej powyżej, biorąc pod uwagę przykład React SDK, musimy zaktualizować odpowiednią konfigurację w LogtoConfig:

Po zalogowaniu się użytkownika free_user do przykładowej aplikacji symulującej aplikację AI Assistant, możemy zobaczyć informacje roles, balance, numOfCallsToday, isPaidUser i isPremiumUser, które dodaliśmy przez przeglądanie części ładunku tokenu dostępu JWT.

Wartości balance, numOfCallsToday, isPaidUser i isPremiumUser są zgodne z poprzednim testem, a roles równa się ["free-user"]. Jest tak dlatego, że w rzeczywistym procesie logowania użytkownika końcowego uzyskamy wszystkie dostępne dane użytkownika i przetworzymy je odpowiednio.

Dla użytkowników premium widać, że roles to ["paid-user"], a zarówno isPaidUser, jak i isPremiumUser są true.

Aktualizacja logiki autoryzacji dostawcy usług#

W poprzednich krokach dodaliśmy niestandardowe roszczenia na podstawie potrzeb biznesowych do tokenu dostępu użytkownika. Następnie możemy użyć tych roszczeń do szybkiego dokonania weryfikacji uprawnień.

Tutaj przedstawiamy logikę weryfikacji tokenów dostępu JWT przez Logto po stronie API. Kompletną implementację kodu można znaleźć w repozytorium GitHub:

Możesz odnieść się do logiki weryfikacji tokenów dostępu API Logto i dostosować ją zgodnie z własną logiką biznesową. Na przykład dla scenariusza aplikacji AI Assistant opisanego tutaj, możesz dodać logikę weryfikacji dla niestandardowych roszczeń, takich jak roles, balance, numOfCallsToday, isPaidUser i isPremiumUser w funkcji verifyBearerTokenFromRequest.

Powyższy przykład dotyczy scenariusza, w którym wpływa to na logowanie użytkownika końcowego i uzyskanie tokenu dostępu JWT. Jeśli twój przypadek użycia dotyczy maszyny do maszyny (M2M), możesz także osobno skonfigurować niestandardowe roszczenia JWT dla aplikacji M2M.

Konfiguracja niestandardowego JWT dla użytkowników nie wpływa na rezultat uzyskania tokenów dostępu przez aplikacje M2M i odwrotnie.

Ze względu na ogólność połączeń M2M, Logto obecnie nie zapewnia funkcji metody getCustomJwtClaims aplikacji M2M do przyjmowania wewnętrznych danych z Logto. W innych aspektach, sposób konfiguracji niestandardowego JWT dla aplikacji M2M jest taki sam jak dla aplikacji użytkownika. W tym artykule nie będziemy tego szczegółowo omawiać. Możesz zacząć korzystanie z funkcji niestandardowego JWT w Logto.

Dlaczego warto korzystać z niestandardowych roszczeń JWT?#

Przedstawiliśmy scenariusz aplikacji AI Assistant dla Johna oraz sposób korzystania z funkcji niestandardowego JWT Logto, aby osiągnąć bardziej elastyczną weryfikację uprawnień. W tym procesie możemy dostrzec zalety funkcji niestandardowego JWT:

1. Bez funkcji niestandardowego JWT użytkownicy muszą za każdym razem, gdy sprawdzają uprawnienia sięgnąć do zewnętrznego API (tak jak to robisz w getCustomJwtClaims). Dla dostawcy usług, który udostępnia takie API, może to zwiększyć dodatkowe obciążenie. Dzięki funkcji niestandardowego JWT te informacje mogą być umieszczone bezpośrednio w JWT, zmniejszając częstotliwość wywołań zewnętrznego API.
2. Dla dostawców usług funkcja niestandardowego JWT może pomóc w szybszym weryfikowaniu uprawnień użytkowników, zwłaszcza gdy klient często wywołuje dostawcę usług, co poprawia wydajność usługi.
3. Funkcja niestandardowego JWT może pomóc szybko wdrożyć dodatkowe informacje potrzebne do uprawnień w biznesie, a informacje te mogą być przekazywane między klientem a dostawcą usług w bezpieczny sposób, ponieważ JWT jest samowystarczalny i można go zaszyfrować, co sprawia, że jest trudny do sfałszowania.

Jednocześnie, ponieważ getCustomJwtClaims jest wykonywany za każdym razem, gdy użytkownik potrzebuje, aby Logto wydało token dostępu, konieczne jest unikanie wykonywania zbyt skomplikowanej logiki i wywołań zewnętrznych API o dużej przepustowości. W przeciwnym razie, użytkownik końcowy może czekać zbyt długo na wynik getCustomJwtClaims podczas procesu logowania. Jeśli twoja getCustomJwtClaims zwraca pusty obiekt, zalecamy tymczasowe usunięcie tego elementu konfiguracyjnego, dopóki rzeczywiście nie będziesz potrzebować go używać.

Podsumowanie#

W tym artykule Logto rozszerzyło podstawowy token dostępu JWT i rozszerzyło funkcję dodatkowych roszczeń JWT, aby umożliwić użytkownikom umieszczanie dodatkowych informacji o użytkowniku końcowym w tokenie dostępu JWT zgodnie z potrzebami biznesowymi, dzięki czemu po zalogowaniu się użytkownika można szybko zweryfikować uprawnienia użytkownika.

Podajemy scenariusz aplikacji AI Assistant Johna i pokazujemy, jak za pomocą funkcji niestandardowego JWT w Logto można osiągnąć bardziej elastyczną weryfikację uprawnień. Wskazujemy również na kilka kluczowych punktów dotyczących korzystania z niestandardowego JWT. W połączeniu z rzeczywistymi scenariuszami biznesowymi użytkownicy mogą umieszczać różne informacje związane z użytkownikami w tokenie dostępu JWT zgodnie z potrzebami biznesowymi, aby dostawca usług mógł szybko zweryfikować uprawnienia użytkownika.