Czy powinienem przechowywać roszczenia użytkowników w tokenie JWT?


18

Korzystam z tokenów JWT w nagłówkach HTTP do uwierzytelniania żądań do serwera zasobów. Serwer zasobów i serwer uwierzytelniania to dwie osobne role robocze na platformie Azure.

Nie mogę się zdecydować, czy mam przechowywać roszczenia w tokenie, czy dołączyć je do żądania / odpowiedzi w inny sposób. Lista roszczeń wpływa na wyświetlanie elementów interfejsu użytkownika po stronie klienta, a także na dostęp do danych na serwerze. Z tego powodu chcę się upewnić, że roszczenia otrzymane przez serwer są autentyczne i sprawdzone przed przetworzeniem żądania.

Przykłady roszczeń to: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Powody, dla których chcę dla nich użyć tokena JWT, to:

  • Lepsza ochrona przed edycją roszczeń po stronie klienta (tj. Hakowaniem listy roszczeń).
  • Nie trzeba sprawdzać roszczeń na każde żądanie.

Powody, dla których nie chcę używać tokena JWT:

  • Serwer autoryzacji musi następnie poznać listę roszczeń ukierunkowanych na aplikacje.
  • Token staje się pojedynczym punktem włamania.
  • Przeczytałem kilka rzeczy, które mówią, że tokeny JWT nie są przeznaczone dla danych na poziomie aplikacji.

Wydaje mi się, że oba mają wady, ale skłaniam się ku włączeniu tych roszczeń do tokena i chcę po prostu kierować tym przez osoby, które wcześniej sobie z tym poradziły.

UWAGA: Będę używać HTTPS do wszystkich żądań API, więc wydaje mi się, że token będzie bezpieczny „wystarczająco”. Używam AngularJS, C #, Web API 2 i MVC5.


czyta to teraz .... i jeśli chcesz, chciałbyś zaktualizować. Byłbym zainteresowany tym, co zrobiłeś, ponieważ stoję w obliczu tego samego ... myślenia i brakuje mi sposobu, w jaki niektóre części mają działać. użytkownik otrzymuje token autoryzacji, ale w jaki sposób roszczenia mają być przenoszone ... czy mógłbyś wyjaśnić swoje ustalenia ... co prawdopodobnie by mi pomogło.
Seabizkit,

Odpowiedzi:


7

Przechowuję tylko oświadczenia identyfikatora (identyfikator użytkownika itp.) (Zaszyfrowane) w moim pliku JWT.

Następnie, gdy otrzymam token na serwerze (API), mogę wykonać wyszukiwanie po stronie serwera (db lub lokalny interfejs API sieci) i pobrać wszystkie powiązania z identyfikatorem użytkownika (aplikacje, role itp.)

Jeśli jednak chcesz włożyć więcej do pliku JWT, po prostu uważaj na jego rozmiar, ponieważ prawdopodobnie zostanie on wysłany przy każdym żądaniu, ale pamiętaj o zaszyfrowaniu poufnych danych roszczenia.


Pozdrawiam, DL. Czy buforujesz role itp. Na serwerze API, czy po prostu trafiasz DB dwa razy za każdym razem, gdy otrzymujesz żądanie? (tj. raz dla ról i raz dla rzeczywistych żądanych danych). Jeśli go buforujesz, chciałbym wiedzieć, jakiej metody używasz. Czy masz również na myśli dalsze kodowanie identyfikatora użytkownika „wewnątrz” już zaszyfrowanego tokena? Dzięki.
Astravagrant,

1
Nie wdrożyłem się jeszcze tak daleko w moją implementację :), ale tak, myślałem o użyciu serwera buforującego, aby w ten sposób nie uderzać bazy danych tak często, a jeśli rola się zmieni, pamięć podręczna może zostać usunięta, aby umożliwić nową zapytanie o ładowanie zapisanej pamięci podręcznej. W moim przypadku prawdopodobnie użyłbym elsticache Amazon AWS, który jest oparty na otwartym memcached, ale łatwiejszy do skonfigurowania i używania.
wchodzący

Myślę też, że lepiej jest uzyskać wszystkie niezbędne informacje na serwerze zasobów i nie przechowywać ich w tokenie.
Mateusz Migała

więc dla każdego żądania dostajesz role użytkowników ... twierdzi ... czy możesz wskazać mi artykuł lub coś, co pokazuje, że jest to wykonalne. obecnie używam sesji, ale szukam lepszego sposobu na zrobienie czegoś, ale wyszukiwanie na każde żądanie nie wydaje się właściwe?
Seabizkit,

3

Wygląda na to, że uwierzytelnianie (kim jest użytkownik) i autoryzacja (co użytkownik może robić) nie są tak podzielone, jak byś chciał.

Jeśli nie chcesz, aby serwer uwierzytelniający wiedział, do czego ma prawo użytkownik, ogranicz roszczenia w tym JWT do identyfikatora użytkownika, tak jak to sugeruje. Możliwe, że inny serwer, znany jako serwer autoryzacji, sprawdzi, do czego użytkownik jest uprawniony.

Serwer autoryzacji może wykonać krok autoryzacji, gdy klient po raz pierwszy przedstawi token uwierzytelnienia. Serwer zasobów wyśle ​​następnie do klienta token zawierający oświadczenia o autoryzacji.

Uwaga: oba JWT powinny być podpisane różnymi kluczami.

Plusy:

  • Uwierzytelnianie i autoryzacja są zarządzane osobno.
  • Serwer zasobów nie musi sprawdzać autoryzacji dla każdego żądania.
  • Interfejs użytkownika ma dostęp do wyświetlania autoryzacji, ale nie może jej edytować.

Kon:

  • Klient musi obsługiwać dwa tokeny zamiast jednego.
  • Dodanie serwera autoryzacji dodaje kolejną ruchomą część do zarządzania.

1
Nie zapominaj, że nawet po sprawdzeniu autoryzacji w interfejsie użytkownika nadal musisz sprawdzić autoryzację po stronie serwera, gdy nadejdzie żądanie.
Chad Clark
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.