Na czym polega oAuth2?

Cześć, mam małe pytanko

W mojej apce Springowej zrobiłem autoryzację za pomocą tokenów JWT. W skrócie - użytkownik podaje login i hasło i dostaje w odpowiedzi podpisany przez serwer token JWT
Potem używa tego tokenu przy żądaniach do chronionych endpointów. Ale jest to zrobione bez żadnego standardu
Chciałbym zrobić to bardziej profesjonalnie i zacząłem czytać, co można zrobić z tym więcej albo jak rozwinąć to, co jest. Natrafiłem na coś takiego jak OAuth2 i zastanawiam się, czy dobrze to rozumiem

Stąd moje pytania:

• Czy Oauth2 stosuję się TYLKO I WYŁĄCZNIE, gdy chce się zapewnić innym aplikacjom możliwość logowania przez nas serwis (częściowy dostęp do danych) tak aby nie musiały one same trzymać userów?
• Czy mogę użyć OAuth2 do stworzenia procesu autoryzacji/logowania tylko dla mojego klienta (apki webowej/mobilnej) - tj. wyrzuciłbym tę część odpowiedzialną za generowanie JWT z aplikacji, a zamiast tego napisałbym Authorization Server zgodny z OAUth2, korzystając z mechanizmów dostępnych w Spring Security. Z tym, że raczej wołały by do niego tylko moje klienty i byłby to zwykły proces autoryzacji/logowania w systemie (nie dostęp tylko do jakiejś części danych), dodatkowo dostosowałbym przepływ do standardów OAUth2. Czy to co piszę tutaj to jakaś głupota

Mirek345 napisał(a):

W mojej apce Springowej zrobiłem autoryzację za pomocą tokenów JWT. W skrócie - użytkownik podaje login i hasło i dostaje w odpowiedzi podpisany przez serwer token JWT
Potem używa tego tokenu przy żądaniach do chronionych endpointów. Ale jest to zrobione bez żadnego standardu

JWT to przecież standard?

Dokładniej mówiąc to alternatywa dla sesji. Zanim JWT stało się popularne informacje usera trzymano albo w ciastkach (jeśli miały być widoczne dla klienta), albo w sesji (jeśli miały być niewidoczne). Wymagało to servera i stanu. Dzięki JWT możemy nadal "schować" sesję przed użytkownikiem, ale u niego samego - przez odpowiednie techniki kryptoficzne.

Mirek345 napisał(a):

Chciałbym zrobić to bardziej profesjonalnie i zacząłem czytać,

JWT jest spoko. Nie ma powodu żeby go nie używać, tbh.

Jeśli nie chcesz JWT, to możesz zrobić zwykłą sesję server-side.

co można zrobić z tym więcej albo jak rozwinąć to, co jest. Natrafiłem na coś takiego jak OAuth2 i zastanawiam się, czy dobrze to rozumiem

Stąd moje pytania:

• Czy Oauth2 stosuję się TYLKO I WYŁĄCZNIE, gdy chce się zapewnić innym aplikacjom możliwość logowania przez nas serwis (częściowy dostęp do danych) tak aby nie musiały one same trzymać userów?

oAuth to jest sposób na zarządzanie i używanie permissionów jakiegoś użytkownika bez wykorzystania credentiali tego użytkownika (czyli np bez loginu i hasła).

• Czy mogę użyć OAuth2 do stworzenia procesu autoryzacji/logowania tylko dla mojego klienta (apki webowej/mobilnej) - tj. wyrzuciłbym tę część odpowiedzialną za generowanie JWT z aplikacji, a zamiast tego napisałbym Authorization Server zgodny z OAUth2, korzystając z mechanizmów dostępnych w Spring Security. Z tym, że raczej wołały by do niego tylko moje klienty i byłby to zwykły proces autoryzacji/logowania w systemie (nie dostęp tylko do jakiejś części danych), dodatkowo dostosowałbym przepływ do standardów OAUth2. Czy to co piszę tutaj to jakaś głupota

Trochę to się mija z celem, bo oAuth nie miał służyć do logowania. To miało być narzędzie żebyś jakiejś aplikacji mógł dać prawa do swojego jakiegoś innego konta. Np jak logujesz się na stack overflow przez githuba, to stack overflow właśnie oAuthem strzela do githuba po Twoją zgodę, ale Ty nie musisz nigdy wpisać loginu i hasła na stacku. Pytanie się pojawia - jakim cudem stack overflow ma dostęp do Twoich prywatnych repozytoriów, skoro nie ma Twojego loginu i hasła - no włąśnie, oAuth.

Implementacja oAuth'a do logowania to wyciąganie niewłaściwego narzędzia do danego celu.

@Riddle dziękuję za odpowiedź

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Mirek345 napisał(a):

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Nie jestem ze świata Javy, ale wiem że Spring to framework. A jak framework to obsługę OAutha powinien mieć wbudowaną. Przynajmniej każdy większy framework webowy który znam ma to wbudowane, więc nie powinieneś tego w ogóle sam implementować tylko użyć tego co już dostarcza framework. Nie mówiąc o tym, że pewnie istnieje kilkanaście bibliotek które możesz w tym celu użyć.

Generalnie nie bierzemy się za samodzielną implementację protokołów uwierzytelniania/autoryzacji czy algorytmów szyfrowania żeby sobie nie zrobić krzywdy. Wyjątkiem są dwie sytuacje:

1. Jesteśmy na tyle doświadczeni że wiemy jak to zrobić dobrze,
2. Robimy to wyłącznie z ciekawości lub dla nauki jako cel sam w sobie i nie chcemy tego nigdzie implementować.

Po twoich pytaniach widać że jesteś świeżakiem w temacie i polecam ci skorzystać z tego co dostarcza twój framework. No chyba że faktycznie chcesz nauczyć się implementować OAutha pisząc swoją własną bibliotekę, ale tu już zostaje tylko jazda ze specyfikacją i implementowanie tego wszystkiego od zera. Wątpię że komuś na forum będzie chciało się prowadzić ciebie za rączkę przez specyfikację protokołu. A specyfikacja jest dostępna tutaj https://datatracker.ietf.org/doc/html/rfc6749

Mirek345 napisał(a):

@Riddle dziękuję za odpowiedź

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Ale masz jakiś powód ku temu?

Rozwiązania się dobiera do problemu - masz jakąś potrzebę, i znajdujesz rozwiązanie (i takim rozwiązaniem może być JWT, może być oAuth, mogą być refresh tokeny, etc.). Ty, mam wrażenie, podchodzisz do tego odwrotnie - czyli jakbyś chciał zrobić coś po coś, ale nie do końca wiadomo co.

Access tokeny i refresh tokeny służą do tego, żeby źródło pozwoleń (w tym wypadku Twój user) mógł odebrać uprawnienie klientowi. Działa to tak, że klient mając access token może odbierać zasoby z servera, ten access token z reguły żyje krótko (30-60 minut), i potem musi użyć refresh tokena żeby dostać nowy access token. I jeśli nie masz innych potrzeb to nie potrzebujesz refresh tokena, po prostu zrób żeby access token żył długo (np rok), i po sprawie. Konieczność dwóch tokenów przychodzi dopiero wtedy kiedy chcesz odebrać klientowi jakieś prawo - wtedy edytujesz server w taki sposób żeby na dany refresh token już nie wysyłał kolejnego access tokena. W ten sposób mając dwa tokeny możesz "żądzić" kto i kiedy dostanie access token.

Przy czym, należy zauważyć że to nie jest jedyny sposób - bo można to samo ogarnąć jednym tokenem, np server może pamiętać który klient ma jaki access token, i na tej podstawie po prostu odmówić dostępu. Ma to taką wadę, że wtedy jest jakby więcej "points of failure", ale za to działa od razu. Dwa tokeny działają wolniej (bo trzeba poczekać aż ważność access tokenu się skończy), i dopiero potem klient traci dostęp.

Dodatkową zaletą dwóch tokenów, jest to że kiedy jakiś atakujący dostanie nasze tokeny - to access tokenu można użyć żeby "hackować", ale tylko przez krótkie okno, np 30 minut. Jeśli refresh token wycieknie, to raczej nic się z nim nie zrobi, bo hacker musiałby znać też clientId żeby dostać nowy access token - chyba że clientId też wycieknie, to wtedy po zawodach już i tak. Ale tak czy tak, i tak każdy ruch teraz leci po SSL, więc szansa że którykolwiek wycieknie jest bardzo mała.

Także moja rada - zastanów się co tak na prawdę chcesz zrobić. Na 99% nie potrzebujesz tego co próbujesz zrobić. Wygląda to bardzo jak przerost formy nad treścią. Jak widzisz, z oAuth2 jest dużo rzeczy które mogą pójść nie tak, więc zastanów się czy na pewno chcesz w to wchodzić.

Jeśli chcesz się po prostu "pobawić" z tokenami, to zrób sobie prostą integrację z jakimś systemem który z niego korzysta np Github, zamiast pisać swój server - napisanie klienta oAuth jest dużo łatwiejsze niż server - i dodatkowo ciężej zrobić jakąś fatalną katastrofę.

Riddle napisał(a):

Mirek345 napisał(a):

@Riddle dziękuję za odpowiedź

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Ale masz jakiś powód ku temu?

"W mojej apce Springowej zrobiłem autoryzację za pomocą tokenów JWT"

Domyślał się, że autor zwyczajnie chce sobie to przećwiczyć w domowych warunkach na własnym projekcie.

RequiredNickname napisał(a):

Riddle napisał(a):

Mirek345 napisał(a):

@Riddle dziękuję za odpowiedź

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Ale masz jakiś powód ku temu?

"W mojej apce Springowej zrobiłem autoryzację za pomocą tokenów JWT"

Domyślał się, że autor zwyczajnie chce sobie to przećwiczyć w domowych warunkach na własnym projekcie.

No to są lepsze sposoby na to IMO.

Riddle napisał(a):

RequiredNickname napisał(a):

Riddle napisał(a):

Mirek345 napisał(a):

@Riddle dziękuję za odpowiedź

Chciałbym jednak mieć te JWT, a czy powinienem stosować refresh tokeny i jak to dobrze zaimplementować?

Ale masz jakiś powód ku temu?

"W mojej apce Springowej zrobiłem autoryzację za pomocą tokenów JWT"

Domyślał się, że autor zwyczajnie chce sobie to przećwiczyć w domowych warunkach na własnym projekcie.

No to są lepsze sposoby na to IMO.

Pewnie, że są

Ja to robiłem tak

johnny_Be_good napisał(a):

Pewnie, że są

Ja to robiłem tak

Ale to jest klient :|

Wypowiadasz się w ogóle nie na temat.

Czyli żeby zrobić bezpieczne logowanie usera i dostęp do danych poprzez API poprzez aplikację Angularową lub mobilną wystarczą same tokeny JWT z długą datą ważności (i ewentualnie jakimś mechanizmem blokowania tokenów)?

Mirek345 napisał(a):

Czyli żeby zrobić bezpieczne logowanie usera i dostęp do danych poprzez API poprzez aplikację Angularową lub mobilną wystarczą same tokeny JWT z długą datą ważności (i ewentualnie jakimś mechanizmem blokowania tokenów)?

Nawet to blokowanie nie jest konieczne.

Tak na prawdę żeby zrobić bezpieczne logowanie tokena wystarczy Ci sesja nawet bez JWT, i będzie dobrze. JWT wymaga odpowiedniego podpisania i enkryptowania tokenów, żeby były bezpieczne. Sesję możesz stworzyć dużo prościej. Zaletą JWT jest tylko i wyłącznie to że można go użyć w środowisku bez servera (ale Twoje takie nie jest, więc jaki sens?). Tylko sobie robisz wysiłek dodatkowy niepotrzebny.

OAuth2 w Spring bootowym świecie polega na tym, że próbujesz każdy-z-każdym kombinację danej wersji zależności OAuth2 startera i konfiguracji javowej, aż zacznie coś tam działać.

Dobry kurs:

https://www.udemy.com/course/enterprise-oauth-for-developers/

Riddle napisał(a):

Dokładniej mówiąc to alternatywa dla sesji. Zanim JWT stało się popularne informacje usera trzymano albo w ciastkach (jeśli miały być widoczne dla klienta), albo w sesji (jeśli miały być niewidoczne). Wymagało to servera i stanu. Dzięki JWT możemy nadal "schować" sesję przed użytkownikiem, ale u niego samego - przez odpowiednie techniki kryptoficzne.

Ciastka niekoniecznie wymagały stanu po stronie serwera.
Wymagały jak miałeś ciasteczka sesyjne, ale np. taki ASP.NET Core domyślnie nie używał sesji tylko wypluwał podpisane ciastko, w którym siedziały claimy użytkownika - sprowadzało się mniej więcej do tego samego co jakiś token typu JWT - chociaż może domyślnie było jeszcze zaszyfrowane? Nie pamiętam.

Poza tym, ja uważam że używanie bezstanowych tokenów na potrzeby "sesji" użytkownika to raczysko i raczej nie przejdzie i tak w jakichś regulowanych środowiskach.