Załóżmy, że mamy użytkownika, który dostał access token i refresh token z endpointu od jwt.
Załóżmy również, że z niewiadomej przyczyny ktoś trzeci pozyskał refresh token danego użytkownika.
Jak w takim przypadku powinien serwer i użytkownik się bronić?
Bo z access token to pół biedy za jakiś czas token (o ile jest krótki) token się przeterminuje, a z refresh token to można uzyskać dostęp tak bez końca.
Dzięki za link, o sesjach to już wiem, że tutaj jwt może być problematyczne, ale co w takim razie jest sprawdzoną w boju ścieżką jeśli chodzi o dostęp do api z urządzenia mobilnego?
Ogolnie jezeli ktos uzyska refresh token to jest po zawodach. Zabezpiecz go tak, by byl niedostepny.
Mozesz dodac troche wyzszy poziom bezpieczenstwa i generowac token w oparciu o udi+,,date+sol, a pozniej je porownywac, ale to duzo pytan rodzi, bo pytania skad zostal skradziony. To wszystko tez mozna obejsc dekompilujec alplikacje i ujawniajac mechanizm.
Mi ogólnie przychodzi na myśl taki myk:
Czy ktoś gdzieś widział coś podobnego? Czy takie podejście może generować dodatkowe problemy?
pan_krewetek napisał(a):
co w takim razie jest sprawdzoną w boju ścieżką jeśli chodzi o dostęp do api z urządzenia mobilnego?
A to urządzenia mobilne nie umieją w normalne sesje? Przecież różnica między Bearer token a ciastkiem jest praktycznie tylko i wyłącznie w nazwie nagłówka HTTP.
Dzięki! Dałeś mi trochę do myślenia. Dziwnym trafem większość materiałów dotyczących aplikacji mobilnych z jakimi mam styczność kieruje do jwt, ale jak sobie zestawiłem wszystkie plusy i minusy to sesje z cookies mają jednak więcej plusów w kontekście projektu nad jakim pracuję.
@pan_krewetek: Słuchaj, używanie JWT w autoryzacji aplikacji jest powszechną praktyką. Nawet w takich frameworkach jak AZURE MSAL się tego używa. Dopóki nie masz ataku xss to ten token będzie bezpieczny. Jak masz podatność na atak xss, to raczej jest po zawodach. To jest duża debata internetowa i stwierdzenie, że ciastka są ok (tutaj też ważne info - tylko http-only), a tokeny są złe, to jest nieuzasadnione uproszczenie. Jest też często taka praktyka, że token się szyfruje krótkim hasłem podawanym przez użytkownika, nie dostępnym w globalnym scopie, ale weź pod uwagę, że jest to skala zabezpieczeń dla serwisów transakcyjnych.
Ps. oczywiście tam jest rozbicie na access token i refresh token, ale to osobna sprawa.
Kwestie bezpieczeństwa tutaj:
https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/
Firebase Auth, Cogito (Amazon Connect), ...