Logto x Hasura: Użycie JWT do kontroli dostępu

Hasura to narzędzie, które może szybko udostępnić odpowiadające twoim danym interfejsy GraphQL i REST API. Z uwagi na bezpieczeństwo danych, Hasura oferuje także możliwość precyzyjnego dostosowania kontroli dostępu do każdego API.

Zazwyczaj użytkownicy Hasura korzystają z innych usług zarządzania tożsamością i uwierzytelniania, a Logto jest jednym z najpopularniejszych wśród nich.

W tym wpisie na blogu założymy, że już korzystasz z usług Hasura. Przedstawimy, jak zintegrować Hasura z Logto, aby zmaksymalizować bezpieczeństwo twoich danych. Jeśli nie masz konta Logto, zarejestruj się i zacznij z niego korzystać teraz!

Tło#

Hasura stosuje zarządzanie dostępem oparte na rolach, podczas gdy Logto używa standardowego zarządzania dostępem opartego na rolach (RBAC).

W modelu Logto i najlepszych praktykach RBAC radzimy użytkownikom, aby używali scope do odpowiadania najdrobniejszym uprawnieniom, używali role jako zbioru scope dla wygodnych operacji grupowych, a ostatecznie sprawdzali scope (zazwyczaj po stronie dostawców zasobów), aby zweryfikować, czy użytkownik może wykonać określoną operację.

W Hasura role odpowiada najdrobniejszym uprawnieniom, a sprawdzanie uprawnień odbywa się na podstawie role. Dlatego podczas konfiguracji Logto zalecamy mapowanie jednej role na dokładnie jeden scope. To podejście może połączyć uprawnienia Logto i Hasura, aby uniknąć zamieszania i nadużyć.

Hasura może obsługiwać kontrolę dostępu za pomocą Webhooków lub JWT. Nasz poprzedni wpis na blogu przedstawiał, jak używać Webhooków, a w kolejnych sekcjach wyjaśnimy, jak wykorzystać kontrolę dostępu Hasura w trybie JWT.

Zaczynamy#

Zacznijmy od prostego przykładu. Załóżmy, że użytkownik już posiada dwa interfejsy API w Hasura, GET /user i PATCH /user, odpowiadające dwóm rolom: user:reader i user:maintainer.

1. Utwórz zasób API Hasura w Logto#

Utwórz zasób API Hasura w Logto.

2. Utwórz role zgodnie z ustawieniem Hasura w Logto#

Musimy utworzyć dwa scope dla zasobu API Hasura wspomnianego w kroku 1, mianowicie read:user i maintain:user, a następnie utworzyć dwie role: user:reader (zawierającą zakres read:user) i user:maintainer (zawierającą zakres maintain:user) w celu dokładnego odwzorowania ról Hasura. Przypisz te role użytkownikom Logto według potrzeb.

3. Skonfiguruj zmienną środowiskową Hasura HASURA_GRAPHQL_JWT_SECRET do włączenia trybu JWT#

Zgodnie z opcje konfiguracji JWT w Hasura, musimy dodać i skonfigurować zmienną środowiskową HASURA_GRAPHQL_JWT_SECRET, zanim będziemy mogli korzystać z JWT do kontroli dostępu.

Istnieje wiele różnych opcji, które można skonfigurować, ale tutaj przedstawiamy najprostszy przypadek: trzeba skonfigurować tylko jwk_url. Wartość tę można uzyskać z punktu końcowego konfiguracji OpenID w Logto (https://your.logto.domain/oidc/.well-known/openid-configuration).

4. Dostosuj dodatkowe roszczenia tokenu dostępu użytkownika#

Korzystając z funkcji Dostosowanego JWT w Logto, dostosuj logikę, aby dodać dodatkowe roszczenia do tokenu dostępu użytkownika w formacie JWT.

Dostosuj metodę getCustomJwtClaims, aby dodać dane do JWT, na których polega Hasura przy implementowaniu kontroli dostępu. Może to obejmować dane związane z użytkownikiem, który jest autoryzowany w danym momencie, w tym jego role, które można uzyskać przez context.

Ustaliliśmy również zmienną środowiskową USER_DEFAULT_ROLE_NAMES, aby uniknąć twardo zakodowanych wartości.

5. Zintegruj Logto SDK#

Po skonfigurowaniu Logto i Hasura, zintegruj swoją aplikację z Logto SDK. Tutaj używamy przykładu Next, aby podglądać token dostępu użytkownika wydawany przez Logto po zalogowaniu użytkownika.

Najpierw przypisujemy wcześniej utworzone role user:reader i user:maintainer użytkownikowi, a następnie logujemy się jako ten użytkownik.

Uzyskaj token dostępu użytkownika i wyślij żądanie do API Hasura:

Podsumowanie#

W tym artykule przedstawiliśmy inną metodę kontroli dostępu opartą na JWT, obsługiwaną przez Hasura, oprócz Webhooka.

Porównując procesy kontroli dostępu Hasura za pomocą Webhook i JWT, możemy zauważyć, że podejście Webhook wysyła webhook do Logto i czeka na odpowiedź dla każdego żądania w Hasura; podczas gdy podejście oparte na JWT może być wykorzystywane ciągle, do momentu, gdy JWT wygaśnie.

Podejście oparte na JWT może zmniejszyć obciążenie sieciowe i wyeliminować opóźnienia sieci wynikające z webhooków; tymczasem podejście oparte na webhookach może synchronizować zmiany w uprawnieniach użytkownika w czasie rzeczywistym.

Użytkownicy mogą wybrać odpowiednie podejście na podstawie tych wniosków oraz swoich rzeczywistych potrzeb biznesowych.