Standard OAuth2 wyjaśniony po ludzku

Standard OAuth2 jest dziś używany praktycznie wszędzie. Znajdziemy wiele przykładów dostępu do facebooka, google itp. Nie ma za to wiele wyjaśnień o co tak naprawdę chodzi. Dziś dowiemy się jakie problemy rozwiązuje i jak działa autoryzacja w tym standardzie.

Mój pierwszy kontakt z Oauth2 wywołał oburzenie. Dlaczego to tak skomplikowane? O co w tym chodzi? Po co wszystkie tokeny, sekrety, trzy strony autoryzacji, kody itp? Zwykłe loginy i hasła działają. Gdy potrzeba lepszego bezpieczeństwa można przecież używać kryptografii asymetrycznej. Po co tak komplikować?

Problemy zwykłej autoryzacji

Okazuje się, że jednak jest sens. Zwykłe metody autoryzacji nie zapewniają pełnego bezpieczeństwa. Zobaczmy na przykładzie.

Przypuśćmy że ktoś, nazwijmy go Adam, wyjeżdża na dłużej. Potrzebuje kogoś, kto będzie podlewał mu kwiatki w domu i karmił rybki. Prosi więc koleżankę o przysługę i daje jej klucz do swojego domu. Jakie to rodzi problemy? Całkiem sporo:

  1. Koleżanka może zgubić klucz do domu Adama. Jeśli ktoś niepowołany znajdzie, kłopoty gotowe. Nie można unieważnić klucza. Trzeba wymieniać zamki.
  2. Ktoś może bez jej wiedzy skopiować klucz, będący w jej posiadaniu. Problemy jak w punkcie 1.
  3. Posiadaczka klucza może być nieuczciwa i sama skopiować sobie klucz.
  4. Oprócz dostępu do kwiatków i rybek koleżanka ma dostęp do całego mieszkania. Może spowodować inne szkody.
  5. Nasza opiekunka rybek może przyprowadzić kogoś znajomego, nawet w dobrej wierze ale ta trzecia osoba może narobić nam szkód
  6. Jeśli przekazaliśmy klucz np. przez kogoś, nie wiemy czy dotarł do właściwej osoby. Ponieważ mówimy tak naprawdę o sieci, wszystko może odbywać się zdalnie.
  7. Zmiana zamków gdy ktoś zgubił klucz unieważnia wszystkie klucze. Trzeba na nowo wykonać kopie kluczy i rozdać je uprawnionym osobom.

To tylko część problemów, które bierzemy sobie na siebie dając klucz (a więc login i hasło) do naszego domu (zasobu) osobie trzeciej. Oauth2 rozwiązuje wszystkie z wyżej wymienionych.

Role czyli kto jest kim w Oauth2

Omawiana metoda definiuje kilka zasadniczych ról. Przyjrzyjmy się im po kolei.

Właściciel zasobu (resource owner) to ktoś, kto rozporządza dostępem. W naszym przypadku jest to Adam – właściciel mieszkania.

Klient (client) jest tym, który chce uzyskać dostęp do zasobu. W przykładzie to nasza koleżanka podlewająca kwiatki.

Zasób (resource server) to aplikacja lub serwis, do której klient chce uzyskać dostęp. W powyższym przykładzie chodzi oczywiście o mieszkanie a konkretnie kwiatki i rybki w nim obecne.

Serwer autoryzacji (authorization server) to aplikacja, która zarządza przydzielaniem kluczy, tokenów i tymczasowych kodów dostępu do zasobu oraz upewnia się, że właściwa osoba dostaje dostęp. W przykładzie z domem nie ma nikogo takiego. Moglibyśmy sobie wyobrazić portiera, ciecia i ochroniarza w jednej osobie. Taki portier sprawdzałby dokumenty każdej wchodzącej osoby i wpuszczał tylko tych, którzy mają prawo wejść.

Mamy też dwa ważne pojęcia, które będą się przewijać w Oauth2:

Zgoda na dostęp (authorisation grant) to umowne potwierdzenie, że klient ma prawo dostępu do określonego zasobu. Zgoda ma formę fizyczną tzn jest kodem, dokumentem lub czymkolwiek co można wydać klientowi.

Token (access token) to fizyczny klucz, kod, karta dostępu lub inna forma pozwalająca faktycznie dostać się do wybranych fragmentów naszego zasobu.

Jak przebiega autoryzacja

Przykład z dostępem do mieszkania nie zapewniał bezpieczeństwa. Jeśli pomyślimy o małej firmie mieszczącej się w nowoczesnym biurowcu będzeimy bliżej metody Oauth2.

Szef firmy (właściciel zasobu) zatrudnia nowego pracownika (klienta). Pracownik po rozmowie kwalifikacyjnej podpisuje umowę. Szef decyduje w jakim dziale nowa osoba ma pracować a więc do jakich fragmentów zasobu ma mieć dostęp.

Pracownik z podpisaną umową idzie do zarządcy (serwera autoryzacji). Zarządca to ktoś, kto wydaje klucze lub karty dostępu do biur, przydziela numery szafek i inne ważne w firmie dostępy. Pracownik pokazuje mu dokument tożsamości i umowę (dane autoryzacyjne). Po sprawdzeniu zarządca wydaje kartę do drzwi (token) a następnie kieruje do odpowiedniego budynku, piętra, korytarza itp.

Pracownik idzie więc z kartą (toeknem) do miejsca, gdzie został skierowany. Natrafia na portiera (zasób). Portier może być elektroniczny (np. czytnik kart otwierający drzwi). Portier sprawdza token i wpuszcza pracownika do jego nowego miejsca pracy.

Gdzie jeszcze występuje Oauth2?

Przykład z dostępem do firmy jest tylko jednym z wielu.

W hotelach również występuje podobny sposób autoryzacji. Recepcja pełni funkcję serwera autoryzacji wydając klucze do drzwi pokojów czyli fragmentów zasobu. W wielu hotelach funkcjonują karty dostępu, które mogą być np. unieważnione gdy gość przekroczy czas pobytu.

Wybierając się w podróż samolotem również przechodzimy wieloetapową kontrolę. Odprawa i kontrola funkcjonują jako serwer autoryzacji sprawdzając paszport i rezerwację (zgodę na dostęp) podczas gdy przed wejściem do samolotu obsługa sprawdza naszą kartę i paszport (oba razem działają jako token).

Czego Oauth2 nie mówi?

Najważniejszą niezdefiniowana rzecz to komunikacja między naszym wydającym karty (serwerem autoryzacji) a portierem (zasobem). Portier musi skądś wiedzieć która karta jest ważna i kogo wpuszczać. Specyfikacja nie mówi jak to robić. Bywa, że wydający karty i portier to ta sama osoba (aplikacja). Jeśli nie, komunikacja między nimi pozostaje w gestii projektantów systemu.

Oauth2 nie mówi też jak ma wyglądać token. Jakie ma pełnić funkcje. Nasz token może np. mieć czas życia, limit jednego lub kilu użyć itp. Możliwości tokena są dowolne.

Szef firmy musi też wiedzieć, że podpisuje umowę z właściwą osobą. Innymi słowy, musimy mieć zaufanie do aplikacji, której dajemy dostęp. Jeśli np. pozwalamy aplikacji w komórce na dostęp do naszego konta na facebooku, musimy jej ufać, że nie będzie wstawiać nam obraźliwych postów ani nie roześle spamu do naszych znajomych.

Dodatkowe możliwości Oauth2

Token odświeżający (refresh token) to dodatkowy element, który możemy zaimplementować w OAuth2. Jeśli np. pracownik po okresie próbnym ma otrzymać dodatkowe uprawnienia, szef może od razu wydać mu dodatkowy dokument (właśnie token odświeżający), z którym później zwróci się do zarządcy aby otrzymać większy dostęp.

Gdy lecimy samolotem z przesiadką, przeważnie nie musimy przechodzić całej kontroli dwa razy. Podczas odprawy otrzymamy dodatkowy bilet, którego użyjemy w strefie odlotów na lotnisku pośrednim.

Co dalej?

Omówiłem jedynie ideę działania standardu OAuth2. Specyfikacja definiuje wiele szczegółów, sposobów przekierowania, punktów przekierowań itp.

Warto przejrzeć przykładowe realizacje Oauth2 na serwisach takich jak facebook, google, github itp. Dla twardogłowych ciekawą lekturą będzie sama specyfikacja Oauth2 zawarta w RFC 6749. Jest też wiele artykułów wyjaśniających standard, np. ten. Specyfikacja definiuje o wiele więcej, niż mogłem opisać w krótkim wpisie.

Schemat autoryzacji jest teraz powszechnie wykorzystywany w praktycznie wszystkich popularnych serwisach. Zwłaszcza tworząc aplikacje serwisowe (SOA) powinniśmy myśleć o dobrych standardach autoryzacji.

8 myśli na temat “Standard OAuth2 wyjaśniony po ludzku”

  1. Nie bardzo rozumiem jak to zaimplementować w przypadku zwykłej strony www która wymagała podania loginu i hasła, kurcze coś nie czuję tematu, gdzieś mam jakąś blokadę w głowie!

    1. W przypadku zwykłej strony wystarczy zrobić podstawową autoryzację przez .htaccess. OAuth2 przydaje się gdy masz kilka serwisów komunikujących się ze sobą i użytkownicy chcą dawać uprawnienia jednemu serwisowi do dostępu do ich konta w innym.

      1. Nie do końca się zgodzę :). W przypadku zwykłych stron (aplikacji) stosowane jest wydawanie tokenów ważnych czasowo. Rozwiązuje to wiele problemów, które podano w tej treści. I wcale nie robi się tego po to by dzielić się zasobami z stroną trzecią.
        – Hasło i login są przekazywane tylko raz
        – na podstawie tego wydawany jest token, który ma określoną ważność
        – serwer najczęściej teraz jest usługą REST i nie przechowuje „stanu” użytkownika zatem użytkownik przy każdej akcji NIE podaje loginu i hasła a właśnie token.

  2. Bardzo podoba mi się sposób wyjaśnienia tej metody. : – ) Jako że jestem umysłem chyba trochę za mało komputerowym, a za bardzo humanistycznym, bardziej rozumiem tłumaczenia podobne właśnie do powyższego. : – )

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *