[API] Wstęp do protokołu OAuth

OAuth jest protokołem open source, który pozwala na bardzo bezpieczną autoryzację do API danego usłogodawcy. Zasada działania polega na wymianie tokenów pomiędzy aplikacją serwerową (udostępniającą jakieś API), a klientem, który z tego API korzysta udostępniając tym samym jakieś funkcjonalności swoim użytkownikom. Protokół ten jest wykorzystywany do autoryzacji praktycznie przez wszystkich liczących się na rynku graczy, jak Google, Facebook, Twitter, czy MySpace.

Dzięki OAuth klient korzystający z danej usługi API (np. korzystający z googlowskiego Dysku za pomocą API Google) może operować na udostępnionym zestawie danych bez konieczności każdorazowego podawania hasła, czy loginu - tym zajmuje się OAuth. Działa to tak - iż aplikacja kliencka korzystająca z OAuth otrzymuje od serwera oferującego uwierzytelnianie OAuth specjalny token oraz secret, które klient umieszcza w swojej aplikacji.

Następnie przy pomocy tych danych użytkownik aplikacji klienckiej loguje się do swoich zasobów u danego dostawcy, określając tym samym do jakich jego danych znajdujących się na serwerze dostawcy dostęp zostanie przydzielony aplikacji klienckiej. Przy okazji rejestracji u dostawcy, klient podaje adres zwrotny, na który OAuth ma zwracać żądanie podczas udanej próby autoryzacji.

Większość dostawców API, jak Google, czy FB udostępnia własne biblioteki do API z wbudowaną implementacją OAuth.
Zasadę działania protokołu bardzo ładnie, choć skrótowo przedstawia ten znaleziony w sieci diagram:

źródło: Google Grafika

W PHP można doinstalować sobie OAuth jako rozszerzenie, lub można też prostszym sposobem - skorzystać z małej biblioteki klienckiej udostępnianej przez protokół. W następnych artykułach przyjrzymy się obu rozwiązaniom. Ponadto nic nie stoi na przeszkodzie, aby postawić swój własny serwer OAuth, co też uczynimy w którymś z kolejnych artykułów, tak aby dobrze przeanalizować zasadę działania protokołu.
Strona protokołu znajduje się pod adresem: http://oauth.net/, manual dla rozszerzenia PHP tutaj: http://php.net/manual/en/book.oauth.php

W protokole OAuth istnieje generalne rozróżnienie na 3 grupy:

• Dostawca [Provider] (np. Google, lub Facebook ze swoim API)
• Aplikacja Kliencka/Klient/Konsument [Consumer, Client], czyli aplikacja korzystająca z usługi Providera i udostępniająca (poprzez pośrednictwo do API Providera) Użytkownikowi jego dane znajdujące się u Dostawcy
• Użytkownik [User] - osoba trzecia, odbiorca końcowy, któryy za pomocą aplikacji klienckiej korzysta z usług jakie oferuje Dostawca. Dane z jakich chce skorzystać Użytkownik muszą należeć do niego.

Warto przyjrzeć się kilku aspektom:

• Dostawca po swojej stronie potrafi rozróżnić Użytkownika od aplikacji klienckiej
• Aplikacja kliencka nie ma dostępu do danych podawanych przez Użytkownika u Dostawcy (np. danych logowania)
• Dostęp do danych zasobów jest ograniczany wg zadanych uprawnień
• To Konsument (aplikacja kliencka) jako pośrednik prosi Dostawcę o udostępnienie Użytkownikowi jego zasobów.
• Nie ma możliwości uzyskania dostępu do danych Użytkownika innych niż te, do których dostęp został zatwierdzony przez Użytkownika

Jeśli chodzi o samo uwierzytelnianie trzeba poznać następujace pojęcia:

• Client/Consumer Key - klucz API wygenerowany dla aplikacji klienckiej (Klienta/Konsumenta)
• Token - losowy ciąg znaków służący do uwierzytelnienia
• Secret - kolejny losowy ciąg znaków przypisany do tokena
• Token żądania (request token) - token używany do autoryzacji, nie umożliwia dostępu do danych
• Token dostępu (access token) - uzyskiwany po weryfikacji za pomocą tokena żądania, umożliwia dostęp do danych

Parametry dla autoryzacji OAuth, czyli dane takie jak np. tokeny można przesyłać na kilka sposobów:

• za pomocą parametrów w adresie URL
• w nagłówkach żądania
• za pomocą POST (np. cURL-em)

Sam protokół OAuth obecnie dzieli się na dwie wersje, różniące się zasadą działania.
Obecnie najczęściej używa się wersji 2, jednakże najpierw opiszmy sobie jak to działa na zasadzie wersji pierwszej:

Pierwsza wersja - OAuth1

Cała operacja wygląda w OAuth1 następująco:

1. Konsument najpierw rejestruje swoją aplikację u Dostawcy i podaje adres zwrotny, na który ma być otrzymywany token żądania.
2. Konsument chce skorzystać z usługi, łączy się z dostawcą podając swój klucz API i prosi o token żądania (request token).
3. Dostawca weryfikuje Konsumenta i wysyła token żądania Konsumentowi na adres zwrotny (callback URL) podany przez Konsumenta.
4. Konsument przekazuje token Uzytkownikowi końcowemu.
5. Następnie Konsument każe Użytkownikowi zalogować się u Dostawcy przy pomocy otrzymanego tokena żądania.
6. Po zalogowaniu się Użytkownika, Dostawca odsyła Użytownika z powrotem do aplikacji Konsumenta, za pomocą adresu określonego podczas rejestracji. W procesie tym Dostawca odsyła zweryfikowany token.
7. Konsument otrzymuje zweryfikowany token i wysyła z jego pomocą token żądania do Dostawcy z prośbą o odesłanie tokena dostępu.
8. Dostawca po weryfikacji wysyła Konsumentowi token dostępu (access token).
9. Użytkownik dostaje dostęp do danych za pomocą aplikacji Konsumenta.

Jest to mniej wiecej przedstawione na poniższym diagramie:

źródło: Stackoverflow

Druga wersja - OAuth2

W drugiej wersji protokołu wygląda to troche inaczej:

1. Konsument najpierw rejestruje swoją aplikację u Dostawcy i podaje adres zwrotny, na który ma być otrzymywany token żądania.
2. Konsument chce skorzystać z usługi, łączy się z serwerem Danych Dostawcy podając swój klucz API, rodzaj (zasięg) danych do jakich chce uzyskać dostęp - tzw. scope i prosi o autoryzację.
3. Serwer danych Dostawcy odsyła Użytkownika do serwera Autoryzacyjnego, gdzie Użytkownik musi się zalogować.
4. Po zalogowaniu się Użytkownik jest z powrotem odsyłany do serwera Danych Dostawcy, gdzie uzyskuje autoryzację i przekazuje ją aplikacji Klienta.
5. Aplikacja Klienta łączy się z serwerem Autoryzacyjnym Dostawcy wysyłając żądanie o otrzymanie tokena dostępu.
6. Serwer Autoryzacyjny Dostawcy przyznaje token dostępu i odsyła go do aplikacji Klienta.
7. Aplikacja Klienta wysyła do serwera Danych Dostawcy żądanie o uzyskanie danych za pomocą tokena dostępu.
8. Serwer Danych Dostawcy weryfikuje token dostępu, ponownie łączy się z serwerem Autoryzacyjnym potwierdzając dane.
9. Dane z serwera Danych Dostawcy są udostępniane aplikacji Klienta.

Jest to mniej wiecej przedstawione na poniższym diagramie:

źródło: Stackoverflow

Przykład działania

Prawdopodobnie powyższy opis jest mało zrozumiały, dlatego podeprzyjmy się przykładem z życia i wyobrażmy sobie jak mogłoby to działać na danym, konkretnym przykładzie.

1. Wyobraźmy sobie, że tworzymy aplikację w PHP, która będzie umożliwiała użytkownikowi wyświetlenie 10 najnowszych wpisów z jego konta na Facebooku. Aplikację nazwijmy np. 10 posts i umieśćmy pod adresem www.10posts.com.
2. Użytkownik chce teraz skorzystać z naszej aplikacji i wchodzi na stronę www.10posts.com. Widnieje tam wielki button o nazwie Pobierz moje 10 postów. Klient klika na przycisk.
3. Nasza aplikacja w tym momencie (identyfikując się kluczem API zarejestrowanym u Facebooka) przypisuje użytkownikowi tymczasowy token i odsyła naszego użytkownika wraz z tym tokenem na stronę logowania Facebooka. Z przekierowaniem tym wysyłany jest też tzw. scope, czyli informacja o tym jakie dane będzie chciała od Facebooka uzyskać nasza aplikacja (w tym przypadku chcemy mieć dostęp do 10 postów) oraz informacja o tym, aby po zalogowaniu się użytkownika Facebook odesłał go z powrotem na stronę naszej aplikacji.
4. Facebook wyświetla użytkownikowi okno do zalogowania się oraz informację o tym, że aplikacja o nazwie 10 posts chce skorzystać z dostępu do treści 10 ostatnich postów.
5. Użytkownik loguje się na stronie Facebooka i wyraża na niej zgodę na takie działanie. Pamiętajmy, że jesteśmy wciąż na stronie FB i tylko FB ma dostęp do wprowadzonych podczas logowania danych, nasza aplikacja takiego dostępu nie ma!
6. Facebook loguje użytkownika i oznacza tokeny, które otrzymał wraz z przekierowaniem na swoją stronę jako zautoryzowane. Następnie wraz z takim zweryfikowanym tokenem odsyła użytkownika z powrotem do naszej aplikacji.
7. Nasza aplikacja dostaje informacje, że użytkownik zalogował się poprawnie i że może kontynuować swoje dalsze działanie.
8. Następnie nasza aplikacja za pomocą otrzymanego od Facebooka zautoryzowanego tokena zamienia ten token na token dostępu (access token) i wraz z takim tokenem wysyła do Facebooka prośbę o otrzymanie listy 10 ostatnich wpisów naszego użytkownika.
9. Nasza aplikacja uzyskuje dostęp do tych danych i pobiera je z Facebooka, a po chwili wyświetla je użytkownikowi na ekranie.

Jak widać, nasza aplikacja uzyskała dostęp do prywatnych danych użytkownika nie uzyskując jednocześnie żadnych kluczowych danych takich jak login i hasło do konta na FB. Aplikacja była jedynie pośrednikiem w przetworzeniu uzyskanej od FB informacji, na której uzyskanie zgodził się użytkownik. Na tym właśnie polega zasada działania protokołu OAuth - aplikacja nie uzyskuje żadnego dostępu do konta użytownika, a jedynie możliwość dostępu do określonych danych, na dostęp do których użytkownik wyraził zgodę u ich Dostawcy.

Na takiej też zasadzie działają wszystkie API dostawców takich jak Google, Facebook, czy Twitter.
Póki co omówiliśmy sobie to w teorii, a w następnych atrykułach zobaczymy jak korzystać z OAuth i określonych API w praktyce.