Czym jest OAuth?

OAuth, czyli Open Authorization, to otwarty standard, który umożliwia użytkownikom przyznawanie aplikacjom zewnętrznym dostępu do ich zasobów bez konieczności udostępniania danych logowania. Zamiast użytkowników ujawniających swoje hasła, OAuth autoryzuje aplikacje innych firm, używając tymczasowych tokenów dostępu do przyznawania dostępu w imieniu użytkownika.

Załóżmy na przykład, że korzystają Państwo z aplikacji innej firmy, takiej jak Mailchimp, popularnego narzędzia do marketingu e-mail, i chcą Państwo zaimportować swoje Kontakty Google, aby utworzyć listę e-mailową. Zamiast ręcznie pobierać i przesyłać każdy kontakt do Mailchimp, OAuth umożliwia Państwu bezpieczne połączenie konta Google z Mailchimp, zapewniając ograniczony dostęp do kontaktów bez ujawniania hasła.

OAuth a OAuth 2.0: jaka jest różnica?

OAuth, czyli OAuth 1.0, wymaga, aby każde żądanie autoryzacji było podpisane podpisem kryptograficznym. Oznacza to, że aplikacja innej firmy musi podpisać żądanie wspólnym tajnym kluczem, który serwer autoryzacji musi odtworzyć, aby zweryfikować żądanie. Podpisy kryptograficzne gwarantują, że żądanie nie zostanie zmienione, ale nie szyfrują danych, więc mogą one zostać przechwycone lub skradzione podczas przesyłania.

OAuth 2.0 upraszcza proces autoryzacji, zastępując podpisy kryptograficzne szyfrowaniem HTTPS, zapewniając bezpieczną transmisję danych typu end-to-end. OAuth 2.0 wykorzystuje krótkotrwałe tokeny dostępu i tokeny odświeżania, aby zwiększyć bezpieczeństwo poprzez zminimalizowanie ekspozycji tokenów. Oferuje również większą elastyczność dzięki obsłudze kilku różnych przepływów autoryzacji w zależności od rodzaju aplikacji, takich jak aplikacje internetowe, aplikacje mobilne i komunikacja serwer-serwer.

Funkcja	OAuth 1.0	OAuth 2.0
Bezpieczeństwo	Używa podpisów kryptograficznych z współdzielonym tajnym kluczem dla każdego żądania. Zapobiega manipulacji, ale nie przechwyceniu.	Używa szyfrowania HTTPS/TLS do bezpiecznej transmisji danych typu end-to-end
System tokenów	Pojedynczy typ tokena bez standardowego okresu wygaśnięcia	Używa krótkotrwałych tokenów dostępu i tokenów odświeżania dla lepszego bezpieczeństwa
Prośba o weryfikację	Zarówno aplikacja, jak i serwer muszą generować zgodne podpisy, aby zweryfikować żądania	TLS obsługuje szyfrowanie i weryfikację żądań
Przepływy autoryzacyjne	Jeden przepływ dla wszystkich przypadków użycia	Wiele przepływów obsługujących różne typy aplikacji (web, mobilne, serwer-serwer)
Złożoność implementacji	Złożone z powodu wymagań dotyczących podpisu kryptograficznego	Prostsza implementacja dzięki poleganiu na protokole HTTPS
Nowoczesne użycie	Rzadziej spotykane w nowoczesnych aplikacjach	Standard branżowy dla nowoczesnych aplikacji
Kompromis bezpieczeństwa	Dodatkowa warstwa zabezpieczeń podpisu, lecz bardziej skomplikowana	Opiera się na zabezpieczeniach TLS, ale jest prostsze do prawidłowego wdrożenia
Zalecane dla	Starsze systemy wymagające weryfikacji podpisu	Większość nowoczesnych aplikacji i interfejsów API

Chociaż zarówno OAuth, jak i OAuth 2.0 są praktycznymi opcjami, zaleca się OAuth 2.0, ponieważ jest łatwiejszy do wdrożenia i częściej stosowany w nowoczesnych aplikacjach.

Jak działa OAuth

Przedstawiamy krok po kroku, jak działa OAuth 2.0 przy użyciu przepływu autoryzacji z użyciem kodu autoryzacyjnego:

Użytkownik inicjuje autoryzację: Użytkownik chce przyznać aplikacji zewnętrznej (zwanej klientem) dostęp do swoich zasobów hostowanych na serwerze. Zazwyczaj rozpoczyna się to, gdy użytkownik kliknie przycisk, taki jak „Log In with Google” lub „Connect to GitHub” w aplikacji klienckiej.
Klient prosi o autoryzację: Klient przekierowuje użytkownika do punktu końcowego autoryzacji serwera autoryzacyjnego. Żądanie zawiera takie parametry, jak: client_id, redirect_uri, response_type=code, scope oraz state (dla ochrony przed CSRF). Następnie użytkownik może zostać poproszony o uwierzytelnienie (jeśli nie jest jeszcze zalogowany) oraz zatwierdzenie lub odrzucenie żądanego dostępu.
Upoważnienie zostało przyznane: Jeżeli użytkownik zatwierdzi żądanie, serwer autoryzacji przekieruje przeglądarkę użytkownika z powrotem do redirect_uri klienta. Kod autoryzacji jest zawarty w adresie URL wraz z parametrem state, który klient powinien zweryfikować, aby upewnić się, że żądanie nie zostało zmodyfikowane ani przechwycone.
Klient prosi o token dostępu: Klient wysyła żądanie do punktu końcowego tokenów, aby wymienić kod autoryzacyjny na tokeny. To żądanie musi zawierać: authorization_code, client_id, client_secret(jeśli dotyczy), redirect_uri (musi odpowiadać oryginalnemu żądaniu) i grant_type=authorization_code.
Klient otrzymuje tokeny dostępu i odświeżania: Jeśli żądanie zostanie zweryfikowane, serwer autoryzacji wydaje token dostępu do uwierzytelniania żądań API oraz token odświeżania do uzyskiwania nowych tokenów dostępu, gdy obecny wygaśnie. Klient przechowuje te tokeny w sposób bezpieczny i używa tokenu dostępu w żądaniach API.
Klient używa tokenu odświeżania: Gdy token dostępu wygaśnie, klient może zażądać nowego, wysyłając żądanie odświeżenia tokena do punktu końcowego tokena. Aby uzyskać nowy token dostępu, klient musi wysłać nowe żądanie do punktu końcowego tokena z następującymi kryteriami: client_id, client_secret, refresh_token oraz grant_type=refresh_token.

Zalety OAuth

Korzystanie z OAuth oferuje kilka zalet, takich jak zmniejszenie ryzyka kradzieży danych uwierzytelniających, poprawa doświadczenia użytkownika i umożliwienie Single Sign-On (SSO).

Zmniejsza ryzyko kradzieży lub niewłaściwego użycia poświadczeń

OAuth eliminuje konieczność udostępniania przez użytkowników swoich danych uwierzytelniających bezpośrednio aplikacjom zewnętrznym. Zamiast tego polega na serwerze autoryzacji do zarządzania dostępem, co znacznie zmniejsza ryzyko ujawnienia danych uwierzytelniających, zwłaszcza w przypadku naruszenia danych. OAuth 2.0 wykorzystuje krótkotrwałe tokeny dostępu, które przyznają ograniczony dostęp do zasobów na określony czas. Tokeny te mogą zostać unieważnione przez użytkownika w dowolnym momencie, co sprawia, że dostęp pozostaje tymczasowy i pod kontrolą użytkownika.

Poprawia doświadczenie użytkownika

OAuth upraszcza doświadczenie użytkownika, umożliwiając dostęp do wielu kont i zasobów przy użyciu istniejących kont, eliminując potrzebę tworzenia oddzielnych nazw użytkowników i haseł dla każdej usługi. Przyspiesza to dostęp i zmniejsza trudności związane z zarządzaniem wieloma zestawami danych logowania.

Umożliwia pojedyncze logowanie

OAuth włącza SSO, pozwalając użytkownikom zalogować się raz u zaufanego dostawcy usług, a potem korzystać z wielu aplikacji bez ponownego wpisywania danych logowania. Dopóki użytkownik pozostaje zalogowany do dostawcy, może bezproblemowo korzystać z innych aplikacji podłączonych do tego samego konta. Na przykład w celu uwierzytelnienia użytkownik może również uzyskać dostęp do aplikacji, które korzystają z Google.

Wady OAuth

Pomimo swoich zalet, OAuth wiąże się z pewnymi zagrożeniami bezpieczeństwa, w tym możliwością przejęcia tokenów, jeśli nie są one bezpiecznie przechowywane lub przesyłane, a użytkownicy mogą nadal być narażeni na ataki phishingowe.

W przypadku przechowywania tokenów w sposób niezabezpieczony istnieje ryzyko ich naruszenia

Tokeny dostępu i tokeny odświeżania są cennymi celami dla cyberprzestępców, ponieważ zapewniają bezpośredni dostęp do danych i zasobów użytkowników. Jeśli tokeny są przechowywane niewłaściwie, podmioty zagrożeń mogą je przejąć, co może prowadzić do nieautoryzowanego dostępu i naruszenia bezpieczeństwa kont.

W przypadku przesyłania tokenów w sposób niezabezpieczony istnieje ryzyko ich naruszenia

Jeśli tokeny są przesyłane przez niezabezpieczone połączenie, takie jak użycie HTTP zamiast HTTPS, mogą zostać przechwycone przez atak typu Man-in-the-Middle (MITM). Po naruszeniu, token może zostać użyty do uzyskania nieautoryzowanego dostępu do zasobów użytkownika.

Podatność na ataki phishingowe

OAuth polega na przekierowywaniu użytkowników na serwer autoryzacji w celu przyznania uprawnień, lecz proces ten można wykorzystać w atakach phishingowych. W ataku phishingowym atakujący nakłania użytkowników do wprowadzania danych uwierzytelniających na fałszywej stronie logowania, która podszywa się pod legalny serwer autoryzacji. Jeśli użytkownicy nie zauważą różnicy, mogą nieświadomie wprowadzić swoje dane uwierzytelniające, dając atakującym dostęp do kont i poufnych danych.