OAuth2 - teoria.

pytanie zadane 16 sierpnia 2019 w Java przez Aisekai Nałogowiec (42,190 p.)

Mam kilka pytań odnośnie OAuth2, chciałbym też powiedzieć, że przeczytałem sporo artykułów, na te tematy, ale dalej nie jestem wszystkiego pewien (będę używał terminologii OAuth2):

1. Czym są scopes? Znalazłem informację, że są one wykorzystywane do ograniczenia uprawnień użytkownikowi (np do tworzenia postów). Tylko w chwili, gdy wykorzystuję Spring Security i role, to to się wydaje jakoś mało pożyteczne. W sensie, jedynie co mi przychodzi do głowy, to żeby poinformować użytkownika do czego ma prawa. Tylko jak w takim razie, wykorzystując Spring Security mógłbym dynamicznie (w zależności od tego, jakie role ma użytkownik o podanej nazwie użytkownika i haśle) dodać odpowiednie scopes? No chyba, że źle rozumiem i scopes są inaczej używane. Tylko jak?

2. O ile dobrze zrozumiałem, to: authorizedGrantTypes przedstawia flow w jaki sposób może być otrzymany token. Jeżeli tworzę system który implementuje OAuth2, jako REST Api, to jaki flow powinienem wybrać? Jeżeli Authorization server i Resource server, to jedna aplikacja, to chyba nie ma znaczenia (jeśli chodzi o bezpieczeństwo) czy użyję password czy client_credentials. Natomiast gdyby to były dwa osobne systemy, to raczej password byłby bardziej odpowiedni, tak? Client by wtedy dodawał Headera Authorization, tak?

3. Czego powinienem używać w Spring Security do autoryzacji? Ról czy Scope?

2 odpowiedzi

odpowiedź 17 sierpnia 2019 przez reaktywny Nałogowiec (40,990 p.)

Odnośnie pierwszego punktu, to scopes to są jakby profile "uprawnień" lub "przywilejów". Czyli mogą być różne profile, z możliwością dostępu do różnych zasobów: np. administrator, moderator czy regularny użytkownik.

A role ponoć są cztery (wg. postu na SO):

In OAuth2, there are the following roles:

Resource owner - usually some person
Auth provider - the OAuth2 server
Resource server - an API that requires an access token and validates its scopes
Client application - application requesting an access token with some scopes.

https://stackoverflow.com/questions/48581556/oauth2-scopes-and-user-roles

Nie wiem jak te scopes przenieść do świata Springa, ale prawdopodbnie tworzy się jakieś dekoratory do metod (kontrollerów) w aplikacji.

komentarz 17 sierpnia 2019 przez Aisekai Nałogowiec (42,190 p.)

W przypadku OAuth2, ról rzeczywiście jest cztery - takie jakie podałeś. Przy czym, te role nie tyczą się autoryzacji (wewnątrz np Resource Servera) tylko bardziej jako określenie co jest czym.

Ja mówię o rolach, jako mechanizmu autoryzacji wraz z (GrantedAuthorities) Spring Security, gdzie żeby użytkownik mógł uderzyć pod jakiś endpoint musi mieć odpowiednią rolę.

Chociaż o ile dobrze teraz myślę, to jedno i drugie to jest to samo (praktycznie to samo), bo OAuth2 to jest protokół, przy czym Authorization Server, może być zupełnie oddzielną aplikacją (czy serwisem), więc on powinien być odpowiedzialny za autoryzację (do czego służą scope), natomiast autoryzacja po stronie Resource Servera, powinna się opierać na tokenie od Authorization Servera. Czyli scope już zrozumiałem, dzięki.

komentarz 17 sierpnia 2019 przez Aisekai Nałogowiec (42,190 p.)

Chociaż nie. Bo jak teraz patrzę na konfiguracje w Springu, to jest pewna nieścisłość. Podam kod, który jest dość intuicyjny, żeby łatwiej było to zaprezentować:

 clients
                .inMemory() //przechowywane w aplikacji, nie zewnetrznym zrodle
                .withClient(clientid)
                .secret(clientSecret)
                .scopes("read", "write")
                .authorizedGrantTypes("password", "refresh_token")
                .accessTokenValiditySeconds(accessTokenValidityTime)
                .refreshTokenValiditySeconds(refreshTokenValidityTime);

jak widać, scopes nie są przypisane do końcowego użytkownika, a do Clienta (w terminologii OAuth2). Więc pytanie, kogo tyczą się te scope? Czy końcowego użytkownika, czy uprawnień Clienta względem Authorization Servera?

komentarz 17 sierpnia 2019 przez reaktywny Nałogowiec (40,990 p.)

Scope dotyczy klienta, nie użytkownika. Opieram się na Baeldungu:

The most important fields from the oauth_client_details we should focus on are:

client_id – to store the id of newly registered clients
client_secret – to store the password of clients
access_token_validity – which indicates if client is still valid
authorities – to indicate what roles are permitted with particular client
scope – allowed actions, for example writing statuses on Facebook etc.
authorized_grant_types, which provides information how users can login to the particular client (in our example case it’s a form login with password)

Please note, that each client has one to many relationship with users, which naturally means that multiple users can utilize a single client.

LINK:

https://www.baeldung.com/spring-security-oauth-dynamic-client-registration

komentarz 17 sierpnia 2019 przez Aisekai Nałogowiec (42,190 p.)

Okej chyba rozumiem. Pozwól, że się upewnię: czyli teraz, jeżeli np Facebook stworzył własny serwer OAuth2 i zezwolił na możliwość zalogowania do innych aplikacji za pomocą Facebooka, to tak naprawdę wystawił Clienta z Scope'ami np. write_statuses, które wewnątrz swojej aplikacji (Resource Server) gdzieś tam (mam na myśli konfiguracje autoryzacji na poziomie REST Api) wykorzystuje scope'y do autoryzacji tak? Czyli każda osoba, wykorzystująca tego Clienta do otrzymania Tokena, otrzyma takie same scope'y - więc takie same uprawnienia?

Edit Oczywiście Client dostarcza Tokena, którego mógłbym użyć do niektórych operacji wykorzystując jakieś REST Api.

komentarz 18 sierpnia 2019 przez reaktywny Nałogowiec (40,990 p.)

Nie będę się rozpisywał w temacie o którym mam średnie pojęcie ;) (żeby nie powiedzieć blade pojęcie). Dlatego podrzucę kilka linków, naprawdę dobrych i po polsku.... Przejrzałem je pobieżnie, ale powinny rozwiać większość Twoich wątpliwości. Szczególnie dobry jest artykuł na Sekuraku (wstęp do oauth oraz terminolgia, etc.). Drugi link też jest dobry (wstęp c.d.) a w trzecim ("kobietydokodu.pl/") masz implemantecję w Springu...

OAuth 2.0 – jak działa / jak testować / problemy bezpieczeństwa

https://sekurak.pl/oauth-2-0-jak-dziala-jak-testowac-problemy-bezpieczenstwa/

Standard OAuth2 wyjaśniony po ludzku – Adam
http://adam.wroclaw.pl/2014/10/oauth2-wyjasniony-po-ludzku/

Projekt Bilet #3 — Konfigurujemy Spring Security oraz OAuth | Kobiety do kodu
https://kobietydokodu.pl/projekt-bilet-3-konfigurujemy-spring-security-oraz-oauth/

Delivery automation - realizuj zamówienia i dostarczaj paczki nawet 60% szybciej - FurgonetkaBiznes
https://biznes.furgonetka.pl/dokumentacja-oauth

odpowiedź 17 sierpnia 2019 przez Wraith Gaduła (4,370 p.)

Nie password tylko passport. Wysylasz do servera Login I haslo a on ci odsyla token i potem kazde zadanie (request) wysylasz z tokenem i wiadomo ze to ty. To najpopularniejsza i najlepsze metoda latwa w implementacji

komentarz 17 sierpnia 2019 przez Aisekai Nałogowiec (42,190 p.)

Rozumiem jak działa password flow (dokładniej Resource Owner Password Flow, https://developer.okta.com/docs/concepts/auth-overview/#implicit-flow ), bardziej mi chodziło o to czy jest jakaś różnica, jeżeli użyję w swojej aplikacji Password lub Client Credentials - ale to już chyba też zrozumiałem.