Standard OAuth2 inspiracją dla rozwiązań bezpieczeństwa w Polish API

15 marca 2019 Grzegorz Abramczyk

Dyrektywa PSD2 wiąże się z udostępnianiem danych o rachunkach bankowych i transakcjach uprawnionym stronom trzecim. Warto więc wiedzieć, na jakich zasadach uprawnienie to będzie ustalane, a dostęp zabezpieczany.

Grzegorz Abramczyk. Od ponad 10 lat buduje rozwiązania dla klientów. Zaczynał swoją karierę w IBM Polska, a obecnie pracuje w firmie TUATARA na stanowisku Architekta IT. Zajmował się większością elementów wytwarzania oprogramowania – od web developmentu do optymalizacji zapytań, od automatyzacji testów do projektowania w UML, od integracji do przewodzenia zespołowi developerskiemu. Po pracy dzieli czas pomiędzy rodzinę, programowanie i gry RPG.

Zgodnie z założeniami dyrektywy PSD2, banki mają obowiązek zapewnić dostęp do informacji o rachunkach swoich klientów uprawnionym stronom trzecim (z ang. Third Party Provider, TPP). To zaś umożliwi TPP świadczenie usług. Uzyskanie takiego dostępu wymaga zawarcia umowy między TPP a klientem. Na jej podstawie uprawniona strona trzecia będzie mogła następnie zwracać się do banków o wydanie danych. Udzielenie przez bank TPP dostępu do danych o rachunkach klienta poprzedzone musi być jednak przez kilka niezbędnych kroków.

Spis treści

Zgoda na dostęp to tylko pierwszy krok

Przede wszystkim przed bankiem staje wyzwanie: jak jednoznacznie ustalić tożsamości klienta, z którym TPP zawarło umowę? Bank musi stwierdzić, czy osoba będąca klientem TPP jest równocześnie klientem banku. Jeśli jest, osoba ta musi zostać przez bank zidentyfikowana.

Znając już tożsamość klienta, bank musi sprawdzić, do jakich danych udzielił on TPP dostępu. Niedopuszczalną przecież byłaby sytuacja, w której klient zezwalałby na dostęp do cudzych danych.

Co więcej, o ile sama umowa dostępu do danych zawierana jest pomiędzy klientem i TPP, to właśnie na banki regulacja PSD2 nakłada obowiązek potwierdzenia udostępnienia danych mechanizmem ”Strong Customer Authentication” (SCA), czyli uwierzytelnienia wieloczynnikowego (Multi-Factor).

Zobacz też

Frontend Fizyka na frontendzie. Jak sprężyny mogą pomóc w tworzeniu efektownych animacji

Mechanizm uwierzytelniania w standardzie OAuth2

Zanim jednak opiszę jakie podejście do powyższego problemu prezentuje Polish API, skupię się chwilowo na elementach standardu OAuth2, stanowiącego w dużym stopniu inspirację dla naszego rodzimego rozwiązania.

OAuth2 jest specyfikacją opisującą proces rozproszonej autoryzacji. Występują w niej cztery główne role:

Klient OAuth — aplikacja pragnąca uzyskać dostęp do danych,
Właściciel Zasobów — osoba posiadająca chronione zasoby, pragnąca je udostępnić klientowi,
Serwer Autoryzacyjny — system odpowiedzialny za zarządzanie dostępem do zasobów,
Serwer Zasobów — system przechowujący i wydający zasoby chronione.

Widoczna jest analogia do PSD2, w ramach której właścicielem zasobów jest klient banku, aplikacja TPP wchodzi w rolę klienta OAuth, a funkcje Serwera Autoryzacyjnego i Serwera Zasobów realizowane są przez systemy banku.

By lepiej zrozumieć OAuth2, musimy rozróżnić dwie kluczowe grupy interakcji, „system-system” oraz interakcje oparte na przekierowaniach.

W interakcjach system-system komunikują się ze sobą systemy informatyczne. Ten rodzaj interakcji ma zarówno plusy, jak i minusy. Oznacza to, że komunikacja może być zabezpieczona na wiele sposobów, np. poprzez zabezpieczenia na poziomie sieciowym, szyfrowanie czy podpisywanie transmisji oraz komunikatów. Z drugiej jednak strony tożsamość użytkownika końcowego (klienta banku) zostaje przekazana jedynie pośrednio, bez jego udziału, i opiera się wyłącznie na zaufaniu do systemu po drugiej stronie.
W interakcjach opartych na przekierowaniu, system źródłowy musi mieć „złapanego” użytkownika końcowego (klienta banku) z otwartą w przeglądarce aplikacją www.

Posługując się mechanizmami protokołu HTTP, serwer źródłowy zleca przeglądarce użytkownika otwarcie adresu udostępniającego przez system docelowy. Otwierając podany adres, przeglądarka może przekazać zestaw parametrów i, co istotne, przekazuje również „złapanego” klienta, który może uwierzytelnić się na stronie banku. Metoda ta jest jednak ograniczona, jeśli chodzi o postać i rozmiar przekazywanych danych i, o ile transmisja może być szyfrowana na poziomie sieciowym, to cały przekaz jest jawny i podatny na modyfikację przez klienta.

OAuth2 definiuje kilka procesów autoryzacyjnych, ten najbardziej dla nas interesujący nazwany Authorization Code Flow, przebiega następująco:

1. Klient OAuth ma „złapanego” w przeglądarce użytkownika i chce uzyskać dostęp do jego zasobów.

2. Klient OAuth przekierowuje użytkownika na adres uwierzytelniający serwera autoryzacyjnego, przekazując swoją tożsamość oraz zakres wnioskowanych uprawnień w parametrze „scope”.

3. Serwer autoryzacyjny ustala tożsamość użytkownika, na przykład poprzez formularz logowania, a następnie potwierdza zgodę na udzielenie dostępu do zasobów.

4. Serwer autoryzacyjny przekierowuje użytkownika na adres powrotu klienta OAuth, przekazując jednorazowy kod autoryzacyjny.

5. Klient OAuth wywołuje wprost (system-system) usługę pobierania tokenów na serwerze autoryzacyjnym i uzyskuje token dostępowy.

6. Klient OAuth pobiera zasoby z serwera zasobów, uwierzytelniając się za pomocą tokenu dostępowego.

Tak opisany proces ma szereg zalet, z których najważniejszą jest to, że użytkownik końcowy nie musi ujawniać swego hasła (lub innych mechanizmów dostępowych) klientowi OAuth. Oznacza to, po pierwsze, że zakres udzielonych uprawnień jest ograniczony, podczas gdy np. udostępnienie hasła pozwoliłoby na pełne przejęcie dostępu użytkownika. Po drugie, unieważnienie dostępu jest możliwe bez zmiany hasła. I odwrotnie, zmiana hasła nie będzie oznaczała unieważnienia wszystkich udzielonych dostępów.

Manipulacjom ze strony użytkownika końcowego zapobiegnie zastosowanie jednorazowego kodu autoryzacyjnego. Użytkownik może go przechwycić, nie będzie jednak w stanie wymienić go na token dostępowy. Standard OAuth2 przewiduje również wykorzystanie mechanizmu tokenów odświeżających (refresh token) pozwalających klientowi OAuth na uzyskanie nowych tokenów dostępowych po wygaśnięciu poprzednich.

Standard OAuth2 nie definiuje procesu autentykacji użytkownika końcowego po stronie serwera autoryzacyjnego. To pole dla rozwoju rozwiązania z zakresu silnego uwierzytelniana, pozwalającego na zastosowanie istniejących mechanizmów logowania do bankowości internetowej czy mobilnej, uwzględniających potwierdzenie autentykacji drugim czynnikiem, takim jak np. kody SMS-owe czy mobilny token. Pozwala to na zastosowanie istniejących mechanizmów logowania do bankowości internetowej czy mobilnej.

Polish API a standard OAuth2

Mechanizm uwierzytelniania klienta po stronie ASPSP (z ang. Account Servicing Payment Service Provider — dostawca usług płatniczych zapewniający i utrzymujący rachunek płatniczy dla płatnika) Polish API jest w wielu kwestiach podobny do uwierzytelniania w ramach standardu OAuth2, jednak istnieje również szereg odstępstw od standardu.

Pierwszym z nich jest rozbicie przekierowania użytkownika na adres autoryzacyjny na dwa kroki. Pierwszym krokiem jest wywołanie system-system, pozwalające TPP przekazać zakres potwierdzanej zgody. W odpowiedzi wygenerowany zostaje unikalny adres przekierowania. Drugim krokiem jest przekierowanie klienta końcowego na otrzymany w ten sposób adres.

Powodów tej zmiany wobec standardu OAuth2 można upatrywać w bardzo rozbudowanym modelu zgód w Polish API, który byłby trudny do uwzględnienia w jednoetapowym przekierowaniu. Standard OAuth2 definiuje zakres uprawnień jako ciąg tekstowych identyfikatorów oddzielonych spacjami. W przypadku Polish API, opisywany jest dostęp do poszczególnych kont, zakresy dat, liczba i częstotliwości wywołań oraz rodzaje dostępnych transakcji. Zamiast więc kodować wszystkie te informacje w „scope”, zaproponowano strukturę danych opartą na JSON. Dodatkowo pojawiła się tu chęć zabezpieczenia przekazywanych danych wszystkimi mechanizmami wymaganymi w komunikacji system-system w Polish API. Nie byłyby one możliwe do zrealizowania w interakcji opartej na przekierowaniu.

Drugą istotną zmianą jest modyfikacja usługi wywołania tokenów. Przede wszystkim zmienia się forma wywołania. Paleta tokenów, dostępowych i odświeżających, poszerza się też o trzeci ich rodzaj, tzw. exchange token. Aby zrozumieć jego zastosowanie, trzeba zdawać sobie sprawę, że w momencie zawierania między TPP a klientem umowy na dostęp do kont, TPP może nie posiadać listy konkretnych kont, których zgoda ta dotyczy. Klient może wyrazić wobec TPP ogólną zgodę, a dopiero potem ją uszczegóławia, wskazując konta po stronie banku. Istnieje także drugi wariant procesu, w ramach którego TPP potwierdza ogólną zgodę na pobranie listy kont klienta, pozwala mu na sprecyzowanie zakresu zgody po swojej stronie, a następnie informuje bank o ostatecznym zakresie zgody. Tu przydaje się exchange token, którego funkcjonalność polega na wymienieniu tokenu zezwalającego na poznanie listy kont na token zapewniający dostęp do wskazanych kont. Exchange token pozwala klientowi uniknąć ponownego logowania do banku. Cała procedura eliminuje obowiązek ręcznego podawania numeru konta.

Mechanizm uwierzytelniania po stronie ASPSP nie jest jedynym definiowanym przez Polish API narzędziem autentykacji. Alternatywę stanowi mechanizm uwierzytelniania w zewnętrznym narzędziu autoryzacyjnym (decoupled). Jego przebieg jest podobny, przy czym przekierowania w przeglądarce zastąpione są tu przepisywanymi przez użytkownika kodami jednorazowymi.

Mimo podobieństw…

Znajomość i zrozumienie standardu OAuth2 mogą okazać się bardzo cenne przy implementacji mechanizmów autoryzacji Polish API. Zmiany wprowadzone względem standardu powodują jednak, że biblioteki i narzędzia obsługujące oryginalny standard, nie poradzą sobie z obsługą Polish API, nie zostawszy wpierw poddanym niezbędnym modyfikacjom.

Zobacz też