Cześć. Nie wiem czy to jest dobre miejsce na takie pytanie ale robię to w springu więc, piszę tutaj. Ostatnio uczyłem się i zaimplementowałem jwt z użyciem refresh tokenów. Wszystko fajnie, refresh tokeny trzymam w bazie danych jako UUID, po stronie klienta trzymam w ciasteczku httpOnly i sameSite a jwt w pamięci. Tylko teraz mnie naszła taka rzecz. Czy to JWT jest mi do czegoś potrzebne? Nie mógłbym w sumie bazować na samym refresh tokenie i przy każdym zapytaniu do serwera pobierać na jego podstawie dane o userze z bazy i dawać mu dostęp na podstawie tych danych lub nie a po stronie klienta trzymać tak jak pisałem w ciasteczku httpOnly i sameSite? Nie było by lepiej i łatwiej? Pojawia się dodatkowe zapytanie do bazy zawsze jedynie.
Spring 
- Rejestracja:prawie 20 lat
- Ostatnio:2 dni
1
JWT na frontendzie to hipsterska moda. Skoro i tak są stanowe (bo te do zewnętrznego użycia muszą być) to czemu nie użyć zwykłych ciastek z ID sesji? Nie musisz trzymać metadanych o zalogowanych użytkownikach w bazie SQLowej, możesz trzymać w Redisie (czy innym key-value store), który jest znacznie szybszy niż SELECTy z typowych baz danych.
edytowany 2x, ostatnio: Wibowit
- Rejestracja:prawie 7 lat
- Ostatnio:ponad rok
- Lokalizacja:Wrocław
- Postów:159
- Rejestracja:około 9 lat
- Ostatnio:około 4 godziny
- Postów:5109
0
np. do cross app/server auth
edytowany 1x, ostatnio: WeiXiao
frontend?
jak by to miało wyglądać? dostaję token z jednego serwera i pcham na inny?
a.com i b.com mają wspólny sekret? co mi da taki schemat?
mają. to, że możesz mieć relatywnie prosto pseudo "sso" bez pisania jakiejś skomplikowanej logiki do tego i martwienia się "a co będzie gdy ktoś zacznie samemu coś majstrować i próbować przesłać coś samemu"
A jak user sie nie zaloguje poprawnie to nawet nie przepuszczasz tego ruchu dalej, tylko odbijasz na api gateway
relatywnie prosto pseudo "sso" bez pisania jakiejś logiki - ta. mam tokena dostępnego z poziomu JSa. co może pójść nie tak? "a co będzie gdy ktoś zacznie samemu coś majstrować i próbować przesłać coś samemu" - właśnie jak token jest dostępny z poziomu JSa to moim zdaniem jest więcej okazji na majstrowanie niż przy ciastku httpOnly. wspólne sekrety? mam dzielić sekret z googlem czy facebookiem?
Pewnie zaklada użycie tej samej domeny, because why not?
Chodzi o to, że nie chcę. Jak działa logowanie np z użyciem konta Google, FB, GH, itp itd? Lecą sobie ciacha, są przekierowania, ale nie ma przenoszenia ciastek między domenami.
@Wibowit: z tego co wiem, to tego typu auth jest właśnie
token based (dziwne, prawie jak json web token xD) https://i.imgur.com/avBmqaB.png
Nie wiem czy tak faktycznie działa OAuth, bo nie korzystałem, ale ja to widzę tak: jestem na
a.com, klikam sign_with_fb (będąc zalogowanym na fb), lecę na facebook.com/cośtam?redirect=a.com/token/ on mnie redirectuje z tokenem do a.com/token/, a token jest jest walidowany przez a.com (w moim przykładzie wyżej fb i a.com znaliby sekret, ale nie wiem czy tak faktycznie jest przy OAuth) i na tej podstawie user jest wlogowywany.
będąc zalogowanym na fb - wydaje mi się, że to zalogowanie jest właśnie dzięki temu, że jest aktywne ciacho przypisane dla domeny fb. Bez tego ciacha musiałbyś wpisywać hasło ponownie. Na końcu dostajesz token (czy tam jakieś inne info o użytkowniku) i to od ciebie zależy gdzie go wpakujesz, normalnie do ciacha httpOnly czy do jakichś ekstra nagłówków. PS: nie analizowałem sprawy do końca, więc mogę się mylić :)
wydaje mi się, że to czy jest to ciacho po stronie fb czy jwt to już szczegół implementacyjny, po prostu facebook ma poświadczyć że Ty to Ty i w jakiś sposób przekazać to do
a.com np. za pomocą tego tokena w url przy redirectcie
Właśnie ciacho wygląda mi na kluczowe. Logując się na fb zapisywane jest ciacho dla domeny fb. Potem to ciacho jest używane przy fb+oauth, bo to się dzieje na domenie fb. Twoja aplikacja do tego ciacha nie ma w ogóle dostępu, więc błędy w niej nie wpływają na ogólne bezpieczeństwo korzystania z fb.
No my raczej pisaliśmy o tym kroku następnym, nie
a.com -> fb.com, a fb.com zwrotka do a.com.<br />
Właśnie ciacho wygląda mi na kluczowe. nie twierdzę że jest to optymalne rozwiązanie, ale dlaczego miałby być problem gdyby wchodząc na tego fb.com z local storage wyciągany był jwt, a następnie backend odpytany o token do a.com i później redirect do a.com/token/ z poziomu jsa?
z poziomu jsa - to jest właśnie ten problem. Ciacha httpOnly są odporne na wiele ataków właśnie przez to, że nie da się ich odczytać z poziomu JSa. https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage it's recommended not to store any sensitive information in local storage.
Przecież to się dzieje na domenie
fb.com, tam nie ma żadnych złych jsów (no może poza tymi od FB :D), czyż nie? Jeżeli nie ufamy FB, to trochę nieracjonalnym jest używanie ich jako auth providera :P
Zresztą tak jak pisałem
nie twierdzę że jest to optymalne - z tym jsem to tylko teoretyzowanie o technicznych możliwościach
Better safe than sorry. Im bardziej ograniczone możliwości dostępu do wrażliwych danych tym lepiej.
Ale to i tak nie jest to o czym pisaliśmy na początku :P tutaj masz
a.com -> fb.com, i teraz w drugą stronę leci token od fb.com do a.com
To co leci z fb.com do a.com to nie jest identyfikator sesji użytkownika na fb.com (który by dawał bardzo duże możliwości) tylko informacje o użytkowniku poświadczone przez fb. Tak czy siak nie ma współdzielenia ID sesji między domenami.
Ja nic takiego nawet nie zasugerowałem że byłoby to jakieś id sesji czy coś :P po prostu token, "specjalny".
No to może inaczej - czy w tym schemacie (komunikacji między a.com i fb.com) JWT jest w jakikolwiek sposób potrzebne? Nie ma znaczenia, czy fb zwróci tokena aplikacyjnego w postaci JSONa, GUIDa czy dowolnej innej.
Tak, ale jak zwrócisz Guida to będziesz musiał go jakoś obsłużyć, jakoś zabezpieczyć przed tym, że ktoś może sobie wrzucać tam losowe guidy i aż trafi usera, a np. JWT zapewni Ci bezpieczeństwo przed modyfikacją, długość życia oraz to, że już jest zaimplementowany w jakichś libkach.
ktoś może sobie wrzucać tam losowe guidy i aż trafi usera - ktoś może też wrzucać jednego i tego samego JWT z różnymi podpisami, aż trafi - przy odpowiednio dobranych rozmiarach guidów i podpisów to będzie tak samo prawdopodobne. długość życia - nie, bo to jest bardzo ograniczone. Co jeśli usunę konto albo zechcę się wylogować z poziomu fb z apek na których jestem zalogowany? w sumie nie wiem czy fb to umożliwia, ale teoretycznie jest to możliwe. Na pewno gmail umożliwia wylogowanie się z innych urządzeń / sesji. Wielorazowego użytku JWT mają podobne problemy wszędzie.
ktoś może też wrzucać jednego i tego samego JWT z różnymi podpisami, aż trafi co masz na myśli? Wielorazowego użytku JWT mają podobne problemy wszędzie. można blacklistować.
co masz na myśli? - mam na myśli to, że JWT jest zabezpieczony przez szyfrowanie albo podpisywanie i tutaj też można to zbrute'ować tak samo "szybko" jak można zbrute'ować równie długiego GUIDa można blacklistować - blacklista to stan po stronie serwera, więc skoro już go mamy to dlaczego nie przenieść do niego wszystkich danych z JWT i tym samym odchudzić przesyłane dane? w ogóle stan po stronie serwera to dużo bardziej elastyczne rozwiązanie niż próby zarządzania świeżością i poprawnością danych w JWT.
Ok,
fb.com odda Ci do serwera guida, i skąd Ty będziesz wiedział co on reprezentuje? jeżeli będzie to id usera, to będzie on zawsze taki sam, czyli słabo. Stosując jwt dostajesz jsona wypełnionego danymi.
Zauważ, że w schemacie na obrazku który podałeś aplikacja robi 2 żądania do fb.com. Jedno (GET /oauth/authorize) jest o zwykły token (czyli GUID), a drugie (GET /me?access_token=... wykorzystujące ten token) jest o dane użytkownika. Mając GUIDa mogę co 5 minut pytać o świeże dane na temat użytkownika, a w drugą stronę fb nie musi sprawdzać świeżości i poprawności danych z tokena bo ich tam nie ma.
Ja nie mowie w ogole o sesji- no to o czym? Ja twierdzę, że na frontendzie lepsze są ciastka z ID sesji, a na backendzie jednorazowe JWT są OK. Do czego się odnosisz?