System oAuth 2.0 w pracy testera

Cześć,

w tym artykule chciałbym przedstawić podstawowe założenia oAuth 2.0 i to w jaki sposób możemy oAuth 2.0 przetestować.

Na samym początku chciałbym zaznaczyć, że framework oAuth 2.0 składa się z różnych możliwych scenariuszy ( grand flows). Poniżej skupię się na jednym z nich- Authorization Code Flow. Jeżeli bedziecie chcieli więcej, dajcie znać w komentarzach poniżej.

oAuth2.0 ze strony użytkownika

Załóżmy, że jesteśmy użytkownikiem ( resources owner), który chce skorzystać z nowej aplikacji do odtwarzania muzyki, aplikacja te będzie nazywana klientem (client). Klient wymaga od nas zalogowania poprzez uzupełnienie całego formularza rejestracji lub daje możliwość połączenia naszego konta, z inną, znaną nam już aplikacją, w której takie konto posiadamy (resource server i równocześnie authorization server) . Wybieramy więc tę drugą opcje i klient przenosi nas na stronę znanej nam aplikacji, a ta po zalogowaniu pyta nas, czy chcemy nadać dostęp dla aplikacji muzycznej, dostęp do określonych ( scope) zasobów- niekiedy nie tylko dostęp do zasobów, ale także konkretne uprawnienia ( permission). Po nadaniu dostępu aplikacja przekierowuje nas z powrotem do strony aplikacji muzycznej ( poprzez redirect_url). Aplikacja pobrała informacje i loguje nas, bądź prosi o dokończenie rejestracji.

Nie wydaje się to skomplikowane. Cały szkopuł polega jednak na tym, że w tle tego wszystkiego ( backendzie) zadział się niewidoczny dla nas proces. Chodzi o moment, który nastąpił po tym, gdy klient połączył się z authorization services pytającym nas o autoryzację. Właśnie ten moment, połączony z nadaniem przez nas dostępu,jest naszym oAuth 2.0. Co więc nastąpiło dalej i jak klient uzyskał ten dostęp? Czy aplikacja po prostu, po naszej zgodzie, go wpuściła? Otóż nie. Najpierw klient otrzymał kod autoryzacyjny (dzięki naszej zgodzie). Kod ten nie pozwala jeszcze klientowi na wejście do serwera bazodanowego. Musi on zostać wymieniony na TOKEN- słowo klucz całego procesu uwierzytelniania klienta. Właśnie token ( Bearer Token) jest kluczem otwierającym konkretne zasoby przed klientem. Na sam koniec dodam tylko, że kod autoryzacyjny nie wystarczy, żeby serwis autoryzacyjny wydał token. Klient, wysyłając requesta z kodem, musi zawrzeć informacje, które go uwierzytelnią przed aplikacją ( client_id i client_secret).

Mamy więc- w podstawowej wersji oAuth 2.0- do czynienia z dwoma procesami. Pozyskanie kodu autoryzacyjnego (dziejące się na frontendzie) i wymiana go na token ( dziejące się na backendzie). Pierwszą część akcji widzimy i bierzemy w niej udział, natomiast druga część (pozyskanie tokena) jest od nas niezależna. To własnie ta druga część powoduje, że proces jest bezpieczny i korzysta z niego wiele znanych nam stron w internecie.

Jak wspomniałem, opisany powyżej flow jest jednym z podstawowych. Istnieją jednak różne jego modyfikacje. Zrozumienie jednak właśnie tego, pozwoli na dużo łatwiejsze przyswojenie następnych.

Słowniczek podstawowych pojęć

Stwórzmy sobie teraz mały słowniczek:

user -> użytkownik, osoba której dane są przechowywane w database server, jedna z kluczowych postaci w całym flow i nadająca dostęp dla klienta

grand flows -> w czasie tworzenia aplikacji zazwyczaj stosuje się modele ścieżek przez jakie musi przejść użytkownik; grand flowy są ścieżkami, które pozwalają uzyskać tokena, czasami dzieją się w tle ( np. client credentials flow) i użytkownik może nie być ich świadomy

client -> aplikacja/ serwis/ platforma, chcąca uzyskać informacje/ uprawnienia przechowywane w database server

database server -> miejsce, w którym przechowywane są nasze dane; często baza danych jest tożsama z authorization server; popularne aplikacje, z którym korzystamy na co dzień np. FB, Google Account itd.

authorization server -> serwer, który umożliwia i nadzoruje przepływ naszych danych między klientem (client), a database server; dystrybuuje kody autoryzacji, tokeny; są na nim przechowywane uprawnienia, zakres danych jakie można pozyskać itd.

scope -> zakres uprawnień przyznawany przez użytkownika klientowi; warto podkreślić, że czasami klientowi zależy na naszych danych, a czasami może to być możliwość edytowania czegoś (CRUD operations)

authorization_code -> kod, który przyznaje klientowi użytkownik; wydawany przez authorization server; wymieniany na tokena

token -> kod, który umożliwia klientowi ( client) wyciągnięcie określonych informacji z database server na nasz temat, w bezpieczny dla nas i zdalny sposób ( tylko określone informacje, bez znajomości naszego hasła)

client_id i client_secret -> informacje o clientencie przechowywane w authorization server na temat danego clienta celem rozpoznania go przy wydaniu tokena ( tak, tylko klient znany dla authorization server może wejść w cały flow, istnieją zatem platformy, które nie mogą skorzystać z systemu weryfikacji oauth2.0 Facebook’a, bo po prostu nie są dla niego znane)

user_credentials -> dane użytkownika, o których dostęp prosi klient

Testowanie oAuth 2.0

Mając powyższą wiedzę, zastanówmy się co my, jako testerzy moglibyśmy przetestować. Nie będę jednak pisał rozbudowanych przypadków i scenariuszy testów, ale postaram się w paru zdaniach opisać co może pójść nie tak.

Chciałbym też podkreślić, że będziemy zastanawiać się nad systemem, który służyć ma jako platforma zarządzająca uprawnieniami nadawanymi zewnętrznym serwisom. Normalnie więc warto byłoby zacząć od tego, czy po implementacji oAuth 2.0, mając właściwy token, jesteśmy w stanie utworzyć konto użytkownika, który może nadawać dostępy- aby jednak sprawdzić taki scenariusz musielibyśmy prześledzić inny GRAND FLOW, w czasie którego, nie wymagamy uwierzytelniania przez użytkownika- opiszę ten flow w następnym artykule jeżeli znajdą się chętni gotowi go przeczytać, a na razie załóżmy, że konto już mamy.

Zaczynamy…

Mamy więc konto. Warto by teraz było sprawdzić, czy w ogóle możemy się “dobić” do naszej platformy, która jest serwisem autoryzacyjnym. Wysyłamy więc zapytanie do frontu (oczywiście przez przeglądarkę):

oAuth 2.0

http://[nasz host]/[endpoint gdzie będziemy się autoryzować]?response_type=code&client_id=[]&redirect_uri=[miejsce gdzie zostaniemy przekierowani po nadaniu właściwego dostępu]&scope=[]&state=[ciąg przypadkowych znaków]

Widzimy po zapytaniu ile rzeczy można sprawdzić. Czy miejsce autoryzacji w ogóle działa; czy nasz klient jest w bazie? Czy jak wpiszemy typ odpowiedzi inny niż “kod” (“code”) to aplikacja zadziała? Czy nasz klient w ogóle zostanie rozpoznany ( został wcześniej wpisany do bazy)?

Gdy uda nam się zalogować, pytamy dalej- czy możemy nadawać uprawnienia określone w zapytaniu, czy taki zakres uprawnień w ogóle istnieje, czy zadany zakres będzie się zgadzał z tym co wyświetli nam aplikacja? Wreszcie, czy dostaniemy kod, widoczny w pasku przeglądarki?

Mając kod, musimy otworzyć jakiegoś klienta REST-owego ( np. POSTAMANA) i zasymulować pracę, która dzieje się na backendzie. Poniżej przykład zapytania:

oAuth 2.0

Pojawiąją się więc nowe pytania. Czy nasz kod może zostać wymieniony na tokena? Czy kod zadziała z innym klientem, czy zadziała gdy użyjemy złego sekretu klienta? Czy nasz endpoint do wymiany kodu na token w ogóle jest zaimplementowany?

Tutaj się zatrzymajmy- możemy przecież, mając tokena, sprawdzić jakie faktycznie ma uprawnienia, ale o tym może innym razem 🙂

Jeżeli artykuł wzbudził w Was jakieś emocje ( mam nadzieję, że pozytywne) to zapraszam do komentowania!

Udostępnij i podziel się z innymi!
  • 10
  •  
  •  
  •  
  • 10
  •  
  •  
  •  

Dodaj komentarz

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Powiadom o