Nie ma wejścia bez uprawnień ? autoryzacja i autentykacja użytkownika

Istnieją dwa podstawowe typy tokenów:

• ?tokeny dostępu?
• ?tokeny ID?.

Tokenem identyfikacyjnym jest JSON Web Tokens (JWTs), który to powinien być używany wyłącznie przez aplikacje.
Przykładem może być fikcyjna aplikacja korzystająca z uwierzytelnienia konta za pomocą gotowego konta Google. Google przesyła do danej aplikacji token identyfikacyjny, w którym to zawarte są informacje na temat użytkownika. Aplikacja analizuje dane z tokena i następnie wykorzystuje istotne informacje takie jak: imię, nazwisko, adres, zdjęcie.

?ID Tokens? nie powinny być używane do uzyskiwania dostępu do interfejsów API.

Zgodnie z OpenID Connect odbiorcą tokenu ID musi być klient z ID aplikacji wysyłającej żądanie uwierzytelnienia. Jeśli ten warunek nie jest spełniony, nie można mieć zaufania dla tokena.
Ten mechanizm działa również w drugą stronę, interfejs API oczekuje tokena z określoną wartością aud, która jest równa unikatowemu identyfikatorowi API.

Tokeny dostępu służą do:

• informowania interfejsu API, że użytkownik dostarczający token, został upoważniony, aby uzyskać dostęp do interfejsu API
• do wykonania z góry ustalonego zestawu działań (ustalonych przez przyznane zakresy).

Tokeny dostępu nie mogą być używane do uwierzytelniania oraz nie są w stanie stwierdzić czy użytkownik uzyskał takowe. Nie zawiera żadnych danych osobowych użytkownika. Jedyne informacje jakie przechowuje token dostępu, to identyfikator.

Aplikacje nie powinny traktować tokenów dostępu jako opaque Strings (nieprzejrzyste ciągi znaków). Nie powinny próbować ich deklarować, ani oczekiwać otrzymywania tokenów w odpowiednim formacie.

JSON Web token to otwarty standard RFC 7519, który definiuje sposób wymiany danych między stronami w bezpieczny sposób przez obiekt JSON.

Informacje zawarte w tokenie są podpisane elektronicznym podpisem co sprawia, że są godne zaufania. JWT może być podpisywany za pomocą tajnego klucza (na algorytmie HMAC) lub kluczy w parach publiczny / prywatny (RSA lub ECDSA).

JSON Web Token może być wykorzystany podczas autoryzacji, wtedy gdy jedna ze strony chce udzielić dostępu do serwisów i zasobów oraz bez magazynowania stanu chce zweryfikować, czy dostęp winien być udzielony.

JWT jako token dostępu może być wykorzystywany również podczas transmisji danych czy też wymiany informacji. Dzięki podpisom par kluczy publiczny/prywatny można być pewnym, że nadawcy są tym za kogo się podają. Podpis jest obliczany dzięki użyciu nagłówka i ładunku. Można również sprawdzić czy treść została zmieniona.

Struktura JWT prezentuje się następująco: xxx.yyy.zzz

• Nagłówek z reguły składa się z dwóch części: informacji o rodzaju tokena czyli JWT oraz algorytmu z jakiego korzystamy czyli HS256, RSA czy też HS512. W następnej kolejności ciało poniższego JSONa zostaje zakodowane w Base64Url i tworzy pierwszą część JWT.

  {
    alg??: ??HS256?
    ?typ?: ??JWT??
  }
  

• Zawartość (PayloadJWT token odpowiada za magazynowanie danych, które zamierzamy przesłać w tokenie. Ponadto tokon zawiera typy informacji takie jak: Registered claims, Public claims, Private claims, Private claims. Prócz informacji o dacie ważności, danych identyfikacyjnych oraz praw użytkownika. Kodowany jest w formacie Base64.

  {
    alg??: ??HS256?
    ?typ?: ??JWT??
  }
  

• Podpis (Verify) cyfrowy potwierdza autentyczność danych, daje pewność że nadawca jest tym za kogo się podaje. Wybierając algorytm HMAC SHA256 będzie tworzony w następujący sposób: HMACSHA256(base64UrlEncode(header) + ?.? + base64UrlEncode(payload), secret). Należy pamiętać, żę secret (hasło) powinien być znaczącej długości oraz zawierać różne znaki.

JSON Web Tokens może zostać wykorzystany do budowy serwisu autoryzacyjnego, w którym możemy uwierzytelnić użytkowników aplikacji. Token, który trafia do serwera jest parsowany, a następnie weryfikowany pod kątem prawidłowości, uprawnień, ważności, TTL i innych.

OAuth 2.0 jest otwartym protokołem umożliwiającym tworzenie mechanizmów autoryzacyjnych z wykorzystaniem różnych platform np. aplikacji mobilnych, webowych i klasycznych. W procesie pozyskania tokenu będzie brał udział: klient, właściciel zasobu oraz serwer autoryzacyjny.

Właściciel zasobu jest to jednostka, która może udzielić dostęp do chronionego zasobu. Z reguły jest to użytkownik końcowy.

Klient jest to aplikacja żądająca dostępu do chronionego zasobu w imieniu właściciela zasobu.

Serwer autoryzacyjny jest to serwer, który uwierzytelnia właściciela zasobu i wydaje tokeny dostępu po uzyskaniu odpowiedniej autoryzacji. W tym przypadku Auth0.

Tokeny dostępu muszą być poufne podczas transportu oraz przechowywania danych. Jedynymi stronami, które powinny zobaczyć token dostępu jest sama aplikacja, serwer zasobów oraz serwer autoryzacji. Token dostępu może być wykorzystywany tylko przez protokoły https, gdyż przekazanie go przez nieszyfrowany kanał mogłoby doprowadzić do łatwego przechwycenia przez osoby niepożądane.

Korzyści z korzystania są wymierne. Klienci, czyli zewnętrzne aplikacje, nie mają styczności z danymi uwierzytelniającymi użytkowników. Istnieje możliwość użycia jednego serwera autoryzacyjnego do ochrony kilku różnych zasobów. Umożliwia to również ograniczenie ilości kont zakładanych w różnych aplikacjach, a przez to niweluje się ryzyko wykorzystania tego samego hasła w różnych aplikacjach.

Metodę pozyskania tokenu musi dopasować do swoich potrzeb. Jeśli klient jest uruchamiany przez www powinniśmy skorzystać z metody Implicit Grant (klient stworzony za pomocą JavaScript). Gdy wiemy, że klient pochodzi z zaufanego źródła i jest np. partnerem biznesowym możemy skorzystać z Client credentials flow (do serwera autoryzacyjnego wysyłany jest tylko identyfikator oraz secret).

Najbardziej prawdopodobnym scenariuszem jest, że klientem jest niezaufana aplikacja, natomiast jednym z elementów procesu jest właściciel w jawnej postaci korzystający z przeglądarki www. Tutaj należy zastosować metodę Authorization Code Flowe.

Do zagrożeń wynikających z wykorzystania OAuth 2.0 można zaliczyć brak szyfrowanego kanału komunikacji. W porównaniu do wersji OAuth 1.0 całkowicie wycofano szyfrowanie kanału komunikacji, dlatego też kluczowe jest szyfrowanie za pomocą TLS. Wyciek jest równoznaczny z wykorzystaniem tokenu przez osoby niepożądane. Klient jest elementem systemu i ma on pewne uprawnienia, które są nadane dzięki generowanemu tokenowi. Na kliencie powierzone jest zadanie przechowywania tokenu w odpowiedni sposób, zarówno w przypadku klasycznych ataków jak i podczas wystąpienia błędu w aplikacji i komunikatu błędu z tym związanego. Dotyczy to tokenu jak i tokenu odświerzającego. Niebezpiecznym jest również przechowywanie tokenów w ciasteczkach przeglądarki, które są narażone na ataki Cross-Site Scription oraz Cross-Site Reguest Forgery.

W porównaniu do wersji 1.0 nastąpiły duże zmiany dotyczące wygodnego zastosowania w różnych scenariuszach biznesowych. O tyle ogromnym minusem jest pozbycie się standardów oraz mechanizmów szyfrujących. Może to powodować różne kontrowersje dotyczące bezpieczeństwa gwarantowanego przez token OAuth 2.0.

Bibliografia:

• https://sekurak.pl/oauth-2-0-jak-dziala-jak-testowac-problemy-bezpieczenstwa/
• https://jwt.io/
• https://www.oauth.com/oauth2-servers/access-tokens/

Autor: Szymon Wasiak, Tester Automatyzujący