OAuth 2.0 – standardowy protokół autoryzacji dostępu, skoncentrowany na ułatwieniu użytkownikowi przepływu autoryzacji dla aplikacji internetowych, aplikacji, telefonów komórkowych oraz innych urządzeń, na których można się zalogować na określone strony internetowe. Protokół OAuth nie wymaga od internauty podawania hasła w momencie logowania, ale zamiast tego używa tokenów autoryzacyjnych(inne języki) (ciąg znaków określających określony zakres, czas życia oraz inne atrybuty dostępu), które mają na celu potwierdzenie tożsamości pomiędzy dostawcami usług a konsumentami. Ogólnie rzecz biorąc jest to protokół, który pozwala na zatwierdzenie współpracy między jedną stroną, aplikacją a drugą w Twoim imieniu, lecz bez podawania haseł. Z takiego rozwiązania korzystają między innymi Facebook, Twitter, Microsoft, Google czy Amazon, chcąc tym samym ułatwić udostępnianie informacji.
Oficjalna strona projektu OAuth 2.0 wyróżniła dokumenty omawiającego specyfikę tego protokołu. Dokument RFC 6749 ↓ jest podstawowym produktem IETF (Internet Engineering Task Force) OAuth Working Group. Docelowo OAuth 2.0 udziela dostępu innemu podmiotowi na przykładzie poniższego praktycznego opisu sytuacji, w której udzielane zostaje prawo do odczytu danych z profilu Facebook bądź Google. Typowy scenariusz opiera się na następujących krokach:
Aplikacja bądź strona internetowa zamierza pozyskać dane użytkownika, w związku z czym pobiera je od zewnętrznego dostawcy tożsamości oraz przekierowuje do serwera autoryzacyjnego
Takowy serwer informuje użytkownika o możliwości uzyskania dostępu do określonych danych (np. dane personalne, adres e-mail).
Decyzja użytkownika polegająca na zaakceptowaniu wymagań aplikacji/strony internetowej jest automatyczną autoryzacją – analogicznie – niezaakceptowanie wymagań nie udziela autoryzacji.
W momencie autoryzacji serwer przekierowuje z powrotem do aplikacji/strony internetowej informacje o udzieleniu zgody.
Aplikacja/strona internetowa otrzymuje token dostęp umożliwiający pobranie wybranych danych o użytkowniku.
W całym procederze chodzi o wygenerowanie tokenu, będącego głównym nośnikiem informacji między podmiotami, które chcą wykonać określoną operację. OAuth może to wykonywać dzięki kompatybilności z protokołem HTTP (ang. Hypertext Transfer Protocol). OAuth ma za zadanie zapewnić „bezpieczny delegowany dostęp” do zasobów serwera w imieniu użytkownika w celu potwierdzenia tożsamości.
Historia
Protokół OAuth zaczął funkcjonować w listopadzie 2006 r., kiedy kanadyjski programista Blaine Cook(inne języki) opracowywał mechanizm OpenID na Twiterze. Chcąc znaleźć sposób na użycie OpenID z interfejsem API Twittera do właściwego uwierzytelnienia skontaktował się z Chrissem Messiną. Podczas spotkania branżowego CitizenSpace OpenID Cook, Messina, David Recordon(inne języki) oraz Larry Halff doszli do wspólnego porozumienia dotychczasowych poczynań w tematyce Open ID. Grupa uznała, że w mechanizmie OpenID Twitter nie było otwartego standardu dla interfejsu API. Kilka miesięcy po spotkaniu, w kwietniu 2007 r. utworzono grupę dyskusyjną OAuth, której celem było zaprojektowanie protokołu otwartego. Dzięki właściwym zastosowaniom Cooka, Messuny, Recordona, Halffa oraz wsparciu DeWitta Clintona z Google w lipcu 2007 r. projekt posiadał zarys oraz specyfikację, natomiast w październiku 2007 r. opublikowana ujednoliconą wersję OAuth Core 1.0.
W listopadzie 2008 roku, podczas 73. spotkania Internet Engineering Task Force (IETF) w Minneapolis poruszony został temat włączenia protokołu do IETF w celu dalszej standaryzacji OAuth. Następstwem tego wydarzenia było stworzenie oficjalnej grupy OAuth na IETF – w kwietniu 2010 protokół OAuth 1.0 został opublikowany jako RFC 5849 ↓.
Aktualizacja protokołu OAuth 1.0 nastąpiła w październiku 2012 r. Nowa struktura OAuth 2.0 została opublikowana jako RFC 6749 ↓, a użycie tokenów na okaziciela jako RFC 6750 ↓.
Wartym podkreślenia jest fakt, że OAuth 1.0 oraz OAuth 2.0 nie są ze sobą kompatybilne, Facebook, Google oraz Microsoft obsługują tylko OAuth 2.0., jako mechanizmu autoryzacyjnego zalecanego dla wszystkich interfejsów API wewnątrz oraz dla stron trzecich.
Dlaczego warto korzystać z protokołu OAuth?
Opisując mechanizm funkcjonowania OAuth, można wnioskować, że jest on rozwiązaniem praktycznym, a korzyści z jego wykorzystywania są następujące:
Właściciel zasobu może udzielić w określonym czasie oraz zakresie dostępu innemu podmiotowi.
Klienci – w tym przypadku aplikacje zewnętrzne, nie mają dostępu do danych uwierzytelniających użytkowników.
OAuth zapewnia autoryzację dostępu do wielu zasobów przy użyciu tylko jednego serwera, dzięki czemu nie trzeba zakładać wielu kont w różnych aplikacjach.
Pojedynczy serwer, wykorzystywany do mnogiej ilości autoryzacji ogranicza ryzyko polegające na powtarzalności tego samego hasła w różnych usługach, a co za tym idzie potencjalnego włamania na jedną z nich.
Potencjalne wady OAuth
Serwer autoryzacyjny – będący niczym innym niż zwykłą aplikacją WWW, która podobnie jak inne tego typu aplikacje jest narażona na ataki zewnętrzne, takie jak np. kwestie bezpiecznego przechowywania poświadczeń, brak lub błędna konfiguracja nagłówków bezpieczeństwa HTTP. Ponadto, warto zadbać o właściwą redundację odporność single point of failure(inne języki) przed atakami odmowy dostępu (ang. Denial of Service). Dalej, kwestią sporną są potencjalne ataki „siłowe”, których można użyć przeciwko serwerowi autoryzującymi – z technicznego punktu widzenia możliwe jest przeprowadzenie prób odgadnięcia tokenu lub danych uwierzytelniających klienta, dlatego też serwer powinien być przygotowany na odparcie takich prób.
Klient (aplikacja, która chce otrzymać dostęp do zasobu) – zadaniem aplikacji jest stworzenie bezpiecznego środowiska dla tokena, by nie dopuścić do jego wycieku np. w przypadku ataku SQL injection.
Tokeny oraz kody dostępu – w przypadku niedopilnowania odpowiednich ograniczeń czasowych może dojść do sytuacji, że tokeny oraz kody dostępu wyciekną np. poprzez ujawnienie ich w logach serwera.
Wykorzystanie OAuth do uwierzytelnienia – głównym założeniem OAuth jest delegowanie autoryzacji, nie poświadczenie uwierzytelnienia – wykorzystanie tokenu na okaziciela powoduje, że każdy, kto posiada taki token, może podszyć się pod wybraną tożsamość. W tym przypadku, szukając mechanizmu, który w poprawny sposób zaimplementuje uwierzytelnienie należy przyjrzeć się protokołowi OpenID Connect, który pozwala na zarządzanie tożsamością właściciela tokenu.
OAuth 1.0 vs. OAuth 2.0
OAuth 2.0 jest unowocześnioną, zaktualizowaną wersją OAuth 1.0. Dla osób, które dotychczas korzystały ze starszego protokołu, przejście na nowsze rozwiązania może się okazać kłopotem, gdyż specyfikacja obu znacznie się zmieniła. Co więcej, oba protokoły nie są ze sobą kompatybilne, dlatego też producenci zalecają ze skorzystania z nowszego standardu podczas tworzenia nowych aplikacji. Widoczne różnice obu protokołów są następujące:
OAuth 2.0 jest znacznie szybszy oraz łatwiejszy do wdrożenia od OAuth 1.0, który wykorzystywał skomplikowane rozwiązania kryptograficzne.
Wersja 2.0 jest wygodniejsza w zastosowaniach biznesowych.
Starszy standard wykorzystywał tylko trzy przypływy, natomiast 2.0 już sześć przepływów, które w znaczny sposób poprawiają obsługę stron bez przekierowywania na przeglądarkę internetową podczas korzystania z aplikacji komputerowych lub aplikacji na telefonach komórkowych. Trzy przepływy zmuszały do:
Przekierowywania użytkownika z aplikacji do przeglądarki w celu otwarcia żądanej usługi
Uwierzytelnienia usługi
Przekierowania oraz skopiowania tokena(inne języki) z powrotem do aplikacji.
Tokeny dostępu(inne języki) w przypadku OAuth 2.0 są szyfrowane podczas przesyłania, nie wymaga się szyfrowania na punktach końcowych jak w wersji poprzedniej.
OAuth 2.0 nie wymaga specjalnego kodowania oraz sortowania.
Tokeny OAuth 2.0 są krótkotrwałe, inaczej oparte na sesji. W przeciwieństwie do tokenów ze standardu 1.0, które mogły być przechowywane w dużym odstępie czasowym (rok, a nawet dłużej), OAuth 2.0 wymaga odświeżania dostępu przez użytkownika.
W teorii OAuth 2.0 okazuje się rozwiązaniem mniej skomplikowanym, udoskonalonym, jednak liczne niedomówienia w oficjalnej dokumentacji OAuth 2.0 sprawiają, że aspekt bezpieczeństwa w tym protokole jest dosyć naciągany. Z owego powodu główny autor specyfikacji projektu – Eran Hammer-Lahav zrezygnował z pełnionej funkcji, wycofał się z grupy roboczej IETF oraz usunął swoje personalia z koncepcji OAuth 2.0. Redaktor podkreślił, że różnica pomiędzy wersjami 2.0 a 1.0 jest bardzo widoczna, ale w negatywnym aspekcie. Według niego OAuth 2.0 stał się „bardziej złożony, mniej interoperacyjny, mniej przydatny, bardziej niekompletny, a co najważniejsze, mniej bezpieczny”. Następnie, z niewyjaśnionych przyczyn z szeregów grupy wycofał się także David Recordon(inne języki), a rolę głównego redaktora – tuż przed oficjalnym opublikowaniem OAuth 2.0 w październiku 2012 r. objął Dick Hardt(inne języki).
SAML vs. OAuth
SAML (Security Assertion Markup Language) jest alternatywnym standardem uwierzytelnienia, sprawdzającym się w rejestracji jednokrotnej (SSO) w wielu przedsiębiorstwach oraz firmach. Dzięki temu rozwiązaniu przedsiębiorstwa mogą monitorować, kto posiada dostęp do zasobów wewnętrznych. Protokół ten dużej mierze jest nastawiony na zachowanie wysokich standardów bezpieczeństwa w przedsiębiorstwach.
SAML uwierzytelnia i autoryzuje dostęp pomiędzy dostawcą usługi oraz dostawcą tożsamości. Ich relacja prezentuje się następująco:
Dostawca usługi przyzwala dostawcy tożsamości na uwierzytelnienie określonych użytkowników.
Dostawca tożsamości generuje potwierdzenie, wskazujące na prawidłowe uwierzytelnienie.
Podstawową różnicą między protokołami SAML oraz OAuth jest to, że pierwszy podczas wymiany informacji uwierzytelnienia korzysta z dokumentów XML (ang. Extensible Markup Language), czyli cyfrowego sposobu podpisu, a OAuth używa JSON (ang. JavaScript Object Notation), będącego formatem tekstowym, bazującym na podzbiorze języka JavaScript. Dalej, kluczową rozbieżnością jest to, że OAuth sukcesywnie korzysta w wywołań interfejsu API, dzięki czemu ten protokół jest rekomendowany przez użytkowników aplikacji mobilnych, nowoczesnych aplikacji internetowych, konsol do gier oraz IoT, a SAML ma możliwość upuszczania tymczasowych plików cookie w przeglądarce.
