2015-08-22 22 views
18

Jestem nowy w JWT. Nauczyłem się trochę o JWT i zrozumiałem, że jest on sformułowany jako "header.claims.signature".Role używające JWT

Rozważmy prosty scenariusz, co następuje:

  • Klient zostaje uwierzytelniony
  • Klient może mieć (jednego lub więcej) role administratora, członek, zarejestrowany, gość
  • Serwer nie utrzymywać żadnych sesja (i zależy wyłącznie od JWT w celu uwierzytelnienia/autoryzacji)

Po uwierzytelnieniu serwer znajduje typ klienta i zakładam, że identyfikator klienta i role będą częścią "roszczeń" w JWT. Daj mi znać, jeśli moje założenie jest nieprawidłowe (lub niezgodne ze standardem).

Część "roszczenia" JWT nie jest zaszyfrowana (tylko zakodowana). Ujawnia to łatwą dziurę w zabezpieczeniach, w której konsument (usługowy) może po prostu zmodyfikować "roszczenia" do części JWT i ponownie wysłać to samo z większą liczbą ról (do których klient/konsument nie ma uprawnień).

Jeśli moje zrozumienie/założenie jest nieprawidłowe, w jaki sposób osiągamy cel, na który jestem nastawiony?

Odpowiedz

18

Podczas korzystania z JWS (header.claims.signature), częścią "JWT" ​​oświadczeń jest integralność chroniona przez podpis. Jeśli więc "roszczenia" lub jakakolwiek inna część JWT zostanie zmodyfikowana przez kogoś bez odpowiedniego klucza, weryfikacja podpisu na JWT nie powiedzie się, a token zostanie odrzucony.

+0

Jeśli zmienię "admin" na "false" na http://jwt.io/, wygląda na to, że podpis nie bardzo się tym przejmuje. Czy coś mi umyka? – user203687

+5

Narzędzie na jwt.io aktualizuje podpis podczas modyfikowania roszczeń JSON. Jeśli chcesz zmodyfikować JWT w innym miejscu i wkleić go, otrzymasz nieprawidłowy podpis zgłoszony przez narzędzie. Na przykład ten JWT ma podpis calculted nad roszczeń w/„admin”: false, ale wówczas roszczenia/ładowność zmodyfikowane do „admin”: true, a więc podpis nie jest ważny: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.uI_rNanTsZ_wFa1VnICzq2txKeYPArda5QLdVeQYFGI –

+0

@BrianCampbell: Excellet! Dokładnie to, czego szukam! –

1

Inną opcją jest wyszukiwanie użytkownika w bazie danych podczas uwierzytelniania, na podstawie identyfikatora użytkownika zawartego w tokenie, w celu zweryfikowania ról lub innych aspektów tożsamości nieuwzględnionych w JWT.

Jednak wszelkie informacje zawarte w JWT są weryfikowane za pomocą podpisu, jak wcześniej podano, więc możesz również polegać na tym, co jest w JWT, jeśli jest to wymagane.

2

Część JWT można zweryfikować, ale innym problemem przy dodawaniu czegoś takiego jak rola do claims jest przypadek, gdy zmieniasz role użytkowników, ale stary token nadal zawiera poprzednie role przypisane do użytkownika. Bądź więc ostrożny. Można po prostu zachować identyfikator użytkownika w tokenie i pobrać wszelkie inne informacje powiązane z użytkownikiem na podstawie mechanizmu trwałości (bazy danych lub cokolwiek innego).