Jak uzyskać token w OAuth2

Niedawno opisywałem filozofię działania schematu OAuth2. Czas zagłębić się w szczegóły. Zajmiemy się dziś najbardziej zawiłą częścią standardu czyli sposobami na dostanie tokena. Zrozumienie tych sposobów zrobi nas speców od OAuth2. ;)

OAuth2 mówi o dwóch rodzajach klientów. Klient zaufany (confidential) to taki, który potrafi dochować tajemnicy. Jeśli otrzyma token, hasło, czy kod autoryzacyjny potrafi nie ujawniać go nikomu.

Odwrotnie mamy też klienta niezufanego (public).  Taki klient nie potrafi zapewnić poufności danych. Wszystkie jego tokeny, hasła i dane można podejrzeć. Chodzi oczywiście o klienty JavaScript, gdzie w przeglądarce nie ma możliwości zachowania poufności danych.

Każdy z tych klientów musi móc otrzymać token. Nie ma innego sposobu dostępu do zasobów niż tokenem. Różne są tylko sposoby aby go otrzymać.

Kod autoryzacji (Authorization Code)

Zaufany klient musi współpracować z przeglądarką. Może mieć przeglądarkę wbudowaną lub korzystać z zewnętrznej. Może to być aplikacja mobilna lub desktopowa. Liczy się to, że musi mieć dostęp do jakiejś przeglądarki.

Klient otwiera stronę autoryzacji (np. logowania do facebooka). Wywołując stronę serwera autoryzacji swoje ID, adres zwrotny oraz zakres danych, o który prosi. My jako właściciel zasobu widzimy stronę z pytaniem np: “Czy chcesz pozwolić aplikacji X na dostęp do Twoich kontaktów i zdjęć?”. Jeśli pozwolimy, serwer przekierowuje na adres podany wcześniej przez klienta.

Klient w przekierowaniu otrzymuje właśnie kod autoryzacji. Teraz może już bezpośrednio (bez przeglądarki) zapytać się serwera autoryzacji o token. Jeśli wszystko jest ok, w odpowiedzi dostaje token aby dostać się do zasobów.

Pośrednia (implict) autoryzacja

Z tej metody korzysta niezaufany klient działający w całości w przeglądarce czyli po prostu aplikacja JavaScript.

Zaczyna się jak poprzednio: kierujemy przeglądarkę pod adres serwera autoryzacji, gdzie użytkownik wpisuje hasło oraz zezwala naszej aplikacji na dostęp. W tym momencie serwer przekierowuje nas na zdefiniowany wcześniej adres.

Tym razem jednak token jest podawany od razu w przekierowaniu. Zdefiniowany wcześniej adres to nasza aplikacja, która podaje w tym miejscu stronę HTML ze skryptem. Skrypt ten może wyłuskać token ze swojego adresu. Token dostajemy jako parametr po hashu a więc jest dostępny jedynie dla JavaScripta.

Niektóre implementacje OAuth2 zamiast pozwalać na przekierowanie od razu w JavaScript przechwytują żądanie i wyłuskują token. Jest to jednak niezgodne ze standardem.

Autoryzacja hasłem użytkownika

Wracamy do starych dobrych haseł. OAuth2 pozwala na autoryzację przez login i hasło. Jeśli mamy bardzo zaufaną aplikację, np. klienta facebooka na komórce, to podajemy jej po prostu login i hasło. Skoro facebook i tak zna nasze dane to nie ma sensu chować ich przed aplikacją facebooka.

Przykładów może być więcej. Możemy mieć do czynienia z archaicznym serwerem dopuszczającym jedynie podstawową autoryzację. Możemy walczyć z innymi zaszłościami w systemach.

Schemat komunikacji jest bardzo prosty. Klient wysyła login i hasło (w jakiś sposób uzyskane od użytkownika). Serwer autoryzacji odpowiada wysyłając token (lub tokeny).

Autoryzacja klientem

Na koniec najprostszy sposób autoryzacji – klient sam z siebie ma mieć dostęp do zasobu.

Jeśli mamy aplikację np. do czytania danych giełdowych z naszego serwisu, nie musimy żądać haseł, zakładania kont itp od użytkowników. Wystarczy zapamiętać, że nasza aplikacja ma dostęp do czytania zasobów.

Nasz klient przedstawia się wcześniej ustalonym kodem autoryzacji. W odpowiedzi dostaje token, którego od razu może uzywać. To wszystko.

Przekierowania i dane klienta

Z powyższych przykładów widać, że serwer autoryzacji musi wcześniej znać ID klienta. Musi też wiedzieć na jakie adresy przekierować. Przeważnie twórca klienta rejestruje go w specjalny sposób. Dostaje od serwisu ID dla swojego klienta oraz może wprowadzić adresy przekierowań.

W ten sposób zabezpieczamy się przed fałszywym klientem. Taki klient znając ID prawdziwego klienta mógłby zarządać przekierowania na fałszywą stronę gdzie otrzyma token. Nie jest to możliwe, jeśli twórca aplikacji musiał wcześniej zarejestrować wszystkie poprawne przekierowania.

Na koniec

OAuth2 bardzo mocno korzysta z protokołu HTTP. Niektóre przekierowania muszą być wręcz wykonywane na bezpiecznych połączeniach. Czy to przez przeglądarkę czy jako inny klient, musimy obsługiwać HTTP.

To oczywiście nie koniec złożoności OAuth2. Standard definiuje rodzaje endpointów (czyli adresów przekierowań) oraz dokładne dane, które muszą być wysyłane przy każdym żądaniu i odpowiedzi. Mówi też o możliwych kodach błędów. Wszystkie informacje znajdziemy w RFC 6749.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *