Czy uprawnienia dostępu i role powinny być uwzględnione w ładunku JWT?

Czy informacje o uprawnieniach i rolach klienta powinny być zawarte w JWT?

Posiadanie takich informacji w tokenie JWT będzie bardzo pomocne, ponieważ za każdym razem, gdy pojawi się prawidłowy token, łatwiej byłoby wyodrębnić informacje o uprawnieniu użytkownika i nie będzie potrzeby wywoływania bazy danych dla tego samego. Ale czy włączenie takich informacji i nie dwukrotne sprawdzenie ich w bazie danych będzie stanowić problem bezpieczeństwa?

Lub,

Informacje takie jak te wymienione powyżej nie powinny być częścią JWT, a jedynie baza danych powinna być używana do sprawdzania ról dostępu i uprawnień użytkownika?

security authentication jwt

— Anshul Sahni
źródło

Odpowiedzi:

Celem włączenia roszczeń do tokena jest uniknięcie komunikacji między zasobem a dostawcą uwierzytelnienia.

Zasób może po prostu sprawdzić, czy token ma prawidłowy podpis i zaufać zawartości.

Zakładając, że klucz prywatny jest prywatny dla serwera uwierzytelniania, jesteś dobry. Niektórzy dostawcy zmieniają klucz, aby zmniejszyć ryzyko.

Jeśli pomyślisz o tym, jeśli zasób oddzwonił do serwera uwierzytelniania, aby uzyskać roszczenia. Następnie zasadniczo zapewnia, że rozmawia z właściwym serwerem za pomocą podobnych metod zaufania.

— Ewan
źródło

Cóż, dziękuję za piękną odpowiedź, czy mogę dowiedzieć się więcej o tym, co miałeś na myśli ze stwierdzenia „Niektórzy dostawcy zmieniają klucz, aby zmniejszyć ryzyko”. ?

— Anshul Sahni

Zamiast mieć ustalony klucz do podpisywania, dostawca uwierzytelniania będzie go zmieniać co jakiś czas i zapewni punkt końcowy dla serwerów zasobów w celu pobrania publicznej połowy. Zasoby muszą nawiązywać połączenia z serwerem uwierzytelniania co jakiś czas, ale nie raz na żądanie

— Ewan

Więc wszystkie tokeny są nieważne za każdym razem, gdy podpis klucza jest zmieniany przez usługę

— Anshul Sahni

zwykle mają więcej niż jeden możliwy klucz, dzięki czemu tokeny lotu nie zostaną unieważnione. token będzie zawierał „identyfikator klucza” informujący zasób, którego użyć

— Ewan

Jedyne, czego mi brakuje, to sposób postępowania, gdy dane w JWT zostaną unieważnione. Powiedzmy, że role zmieniły się po stronie serwera, ale klient nadal trzyma token z całym zestawem ról. Musisz mieć możliwość odwołania tokenów po stronie serwera, aby tokeny zawierające nieaktualne informacje nie były już ważne i nadawały się do dalszych żądań. Jest to zgodne z tym, co Ewans w jakiś sposób sugeruje (pozwalając serwerowi odwołać token) z jednego lub innego powodu.

— Laiv

Z mojego doświadczenia wynika, że jeśli wszystkie systemy korzystają z centralnej bazy danych ról i uprawnień, możesz dodać to wszystko do JWT.

Jednak to podejście może nie działać dobrze w scenariuszach jednokrotnego logowania, gdy sam serwer uwierzytelniający nie ma pojęcia o systemie docelowym, który odbierze i zaufa tokenowi.

Role i uprawnienia użytkownika spoczywają całkowicie na odbiorcy tokenu JWT. Jest to szczególnie prawdziwe, gdy integrujesz uwierzytelnianie jednokrotnego logowania z JWT w niektórych starszych systemach, które mają już swój podsystem zezwoleń, a zatem potrzebują tylko jednego oświadczenia, aby być obecnym w JWT - oświadczenie o tożsamości użytkownika.

— JustAMartin
źródło

Zgadzam się z tym. Uprawnienia użytkownika nie powinny być częścią jwt specjalnie w SSO, ponieważ idp nie jest świadomy, z jakimi innymi usługami ten użytkownik jwt będzie rozmawiać .. zamiast tego zasób powinien zaimplementować część autoryzacyjną po potwierdzeniu tożsamości użytkownika

— Manish Rawat

Zgadzam się również, że wnioski o zezwolenie w JWT nie są dobrym pomysłem poza prostym monolitycznym API. Napisałem o tym post na blogu: sdoxsee.github.io/blog/2020/01/06/…

— sdoxsee