OAuth 2.1 jest tutaj: Co musisz wiedzieć

Wprowadzenie#

Od czasu, gdy OAuth 2.0 (RFC 6749) pojawił się w 2012 roku, świat aplikacji internetowych i mobilnych bardzo się zmienił. Ludzie przenoszą się z komputerów na urządzenia mobilne, a aplikacje jednostronicowe (SPA) są teraz bardzo popularne. Widzieliśmy również, jak pojawiło się wiele nowych frameworków i technologii internetowych. Wraz z tymi zmianami wzrosły również wyzwania związane z bezpieczeństwem. Aby nadążyć za najnowszymi technologiami internetowymi, nowe RFC, takie jak Proof Key for Code Exchange (PKCE), były systematycznie wydawane w celu wzmocnienia OAuth 2.0. Stało się to kluczowe, aby zgrupować wszystkie najlepsze praktyki w zakresie dzisiejszych wymagań dotyczących bezpieczeństwa, co jest powodem, dla którego pojawia się OAuth 2.1.

W nadchodzącym OAuth 2.1 grupa robocza OAuth ma na celu skonsolidowanie wszystkich najlepszych praktyk i zaleceń dotyczących bezpieczeństwa w jednym dokumencie. W Logto zawsze przywiązujemy dużą wagę do najnowszych standardów i najlepszych praktyk związanych z OAuth. W tym artykule przyjrzymy się kluczowym różnicom między OAuth 2.0 a OAuth 2.1 oraz jak zostały one zaadaptowane w Logto.

PKCE jest teraz wymagany dla wszystkich klientów OAuth używających Authorization Code flow#

Jedną z najważniejszych zmian w OAuth 2.1 jest to, że Proof Key for Code Exchange (PKCE) jest teraz wymagany dla wszystkich klientów OAuth używających Authorization Code flow. PKCE jest rozszerzeniem bezpieczeństwa, które zapobiega atakom przechwytywania kodu autoryzacji. Jest to szczególnie przydatne w przypadku aplikacji mobilnych i jednostronicowych (SPA), gdzie tajny klucz klienta nie może być bezpiecznie przechowywany.

Aplikacje OAuth można podzielić na dwa różne typy w zależności od ich zdolności do bezpiecznego przechowywania tajemnic:

1. Klienci poufni: ci klienci mogą bezpiecznie przechowywać tajemnice, takie jak aplikacje internetowe renderowane na serwerze i serwery internetowe. Wszystkie żądania związane z autoryzacją są wykonywane po stronie serwera, a ryzyko ujawnienia tajnego klucza klienta jest niskie.

2. Klienci publiczni: ci klienci nie mogą bezpiecznie przechowywać tajemnic, takie jak aplikacje mobilne i SPA. Tajny klucz klienta może być łatwo wyodrębniony z kodu po stronie klienta i trudno go chronić przed atakującymi.

Dla klientów publicznych PKCE jest niezbędnym środkiem bezpieczeństwa. Zapewnia on, że kod autoryzacyjny może zostać wymieniony tylko przez klienta, który zainicjował żądanie autoryzacyjne.

PKCE działa poprzez generowanie losowego sprawdzania kodu i wyzwań dotyczących kodu opartego na sprawdzanym kodzie. Kod sprawdzania jest wysyłany do serwera autoryzacyjnego, a wyzwanie dotyczące kodu jest wykorzystywane do weryfikacji kodu sprawdzania podczas wymiany kodu autoryzacyjnego na żeton dostępu.

W OAuth 2.1 PKCE staje się obowiązkowe dla wszystkich aplikacji OAuth korzystających z Authorization Code flow, bez względu na ich stan poufności—czy to klienci poufni, czy publiczni. Ta kluczowa zmiana zapewnia uniwersalną ochronę przed potencjalnymi atakami na przechwytywanie kodu autoryzacyjnego.

W Logto proces weryfikacji PKCE jest automatycznie aktywowany dla obu klientów: publicznych i poufnych.

Dla SPA i aplikacji mobilnych PKCE jest niezbędnym środkiem bezpieczeństwa do ochrony Authorization Code flow w Logto. Każde żądanie autoryzacyjne, które nie zawiera wyzwania dotyczącego kodu, zostanie natychmiast odrzucone przez serwer autoryzacyjny Logto.

Jeśli chodzi o klientów poufnych (tradycyjne aplikacje internetowe), dla lepszej zgodności z przeszłością, Logto nadal pozwala na pominięcie wyzwania dotyczącego kodu w żądaniu autoryzacyjnym. Jednak zdecydowanie zachęcamy klientów poufnych do przyjmowania PKCE poprzez wprowadzenie wyzwania dotyczącego kodu w żądaniu autoryzacyjnym, zgodnie z praktykami klientów publicznych.

Dokładne dopasowanie przekierowań URIs#

Przekierowanie URI (Uniform Resource Identifier) jest specyficznym punktem końcowym lub adresem URL, na który serwer autoryzacyjny przekierowuje użytkownika po zakończeniu procesu uwierzytelniania i autoryzacji.

Podczas przepływu OAuth aplikacja klienta zawiera przekierowanie URI jako część początkowego żądania autoryzacyjnego. Gdy użytkownik zakończy proces uwierzytelniania, serwer autoryzacyjny generuje odpowiedź zawierającą kod autoryzacyjny i przekierowuje użytkownika z powrotem na określony URI przekierowania. Jakiekolwiek odejście od oryginalnego przekierowania URI prowadzi do wycieku kodu lub żetonu.

Dokładne dopasowanie ciągu znaków przekierowania URIs zostało po raz pierwszy wprowadzone w OAuth 2.0 Security Best Current Practices sekcja 4.1. Praktyka ta gwarantuje, że URI przekierowania musi dokładnie odpowiadać temu, który jest zarejestrowany na serwerze autoryzacyjnym. Jakiekolwiek odejście od zarejestrowanego URI przekierowania skutkuje błędną odpowiedzią.

Otrzymaliśmy wiele próśb ze strony społeczności o wprowadzenie dopasowywania symboli wieloznacznych dla URIs przekierowania. Chociaż dopasowywanie symboli wieloznacznych może oferować wygodę programistom zarządzającym wieloma subdomenami lub ścieżkami, szczególnie z dużą liczbą losowych subdomen, wprowadza również ryzyka bezpieczeństwa, takie jak ataki z otwartym przekierowaniem. Dla praktycznej ilustracji zagrożeń związanych z brakiem walidacji URI przekierowania zapoznaj się z naszym postem na blogu Krótka recenzja bezpieczeństwa OAuth.

W zgodzie z rygorystycznymi standardami bezpieczeństwa OAuth 2.1 Logto używa dokładnego dopasowania ciągu znaków przekierowania URIs. Tę decyzję podjęto, aby priorytetem było bezpieczeństwo przepływu OAuth. Zamiast używać dopasowywania symboli wieloznacznych, zachęcamy programistów do rejestracji wszystkich potencjalnych URIs przekierowania na serwerze autoryzacyjnym Logto. Zapewnia to dokładną walidację URIs przekierowania i pomaga złagodzić potencjalne luki w bezpieczeństwie.

Implicit Flow jest wycofany#

Implicit Grant Flow w OAuth 2.0 został zaprojektowany dla aplikacji SPA, gdzie żeton dostępu jest zwracany bezpośrednio we fragmencie URL po uwierzytelnieniu użytkownika. Ta metoda była wygodna, ponieważ unikała dodatkowego kroku wymiany żetonu, umożliwiając klientowi bezpośrednie odbieranie żetonu.

Jednak ta wygoda ma swoje minusy. Żeton dostępu może być narażony na nieautoryzowany dostęp poprzez historię przeglądarki, nagłówki referrer lub inne sposoby, co ułatwia naruszenie bezpieczeństwa, zwłaszcza gdy żetony dostępu pozostają ważne przez dłuższy czas. Na przykład, jeśli żądanie autoryzacyjne zostanie przechwycone przez złośliwą stronę, mogą oni łatwo wyodrębnić żeton dostępu z fragmentu URL i podszywać się pod użytkownika.

W OAuth 2.0 Security Best Current Practices jasno stwierdzono:

Klienci NIE POWINNI używać Implicit Grant (typu odpowiedzi "token") lub innych typów odpowiedzi wydających żetony dostępu w odpowiedzi na autoryzację.

Zatem Implicit Flow został oficjalnie usunięty z specyfikacji OAuth 2.1.

W Logto Authorization Code Flow z PKCE jest jedynym obsługiwanym przepływem dla SPA i aplikacji mobilnych. Authorization Code Flow zapewnia bardziej bezpieczny sposób na uzyskanie żetonów dostępu poprzez wymianę kodu autoryzacyjnego.

Grant typu Resource Owner Password Credentials (ROPC) jest wycofany#

Grant typu Resource Owner Password Credentials (ROPC) pozwala klientowi wymienić nazwę użytkownika i hasło użytkownika na żeton dostępu. Został on po raz pierwszy wprowadzony w specyfikacji OAuth 2.0 jako sposób na wsparcie aplikacji dziedzicznych, takich jak podstawowa autoryzacja HTTP lub dziedziczne aplikacje natywne, które nie mogły korzystać z bardziej bezpiecznych przepływów żetonowych OAuth.

Typ grantu ROPC został oznaczony jako niezalecany w specyfikacji OAuth 2.0 ze względu na ryzyka związane z bezpieczeństwem. Poświadczenia użytkownika są eksponowane dla aplikacji klienta, co może prowadzić do potencjalnych naruszeń bezpieczeństwa. Aplikacja klient może przechowywać poświadczenia użytkownika, a jeśli aplikacja klienta zostanie skompromitowana, poświadczenia użytkownika mogą być ujawnione atakującym.

Później, w OAuth 2.0 Security Best Current Practices sekcji 2.4 zakaz stosowania typu grantu ROPC został bardziej podkreślony jako NIE POWINNA być stosowana. W wyniku tego grant ROPC został usunięty z specyfikacji OAuth 2.1.

Z powodu wysokiego ryzyka związanego z bezpieczeństwem z typem grantu ROPC Logto nigdy go nie obsługiwał. Jeśli nadal używasz przepływu bezpośrednich poświadczeń użytkownika w swoich aplikacjach dziedzicznych, zdecydowanie zalecamy migrację do bardziej bezpiecznego sposobu, takiego jak Authorization Code flow lub Client Credentials Grant. Logto oferuje różne SDK i samouczki, aby pomóc Ci bez trudu zintegrować te bezpieczne przepływy OAuth w swoich aplikacjach.

Rozumiemy, że programiści mogą chcieć zaprojektować lub samodzielnie hostować własny interfejs logowania użytkownika dla najlepszych wrażeń z produktu. W Logto oferujemy różne opcje dostosowywania doświadczeń logowania (SIE), w tym ustawienia marki oraz niestandardowe CSS. Dodatkowo mamy kilka trwających projektów, takich jak przynieś własny interfejs użytkownika i bezpośrednie logowanie, aby zapewnić większą elastyczność programistom, którzy chcą dostarczać własny interfejs logowania, zachowując jednocześnie bezpieczeństwo przepływu OAuth.

Zakończenie#

OAuth 2.1 jest najnowszą aktualizacją protokołu OAuth, skoncentrowaną na radzeniu sobie z dzisiejszymi wyzwaniami bezpieczeństwa, jednocześnie uwzględniając nowoczesne potrzeby aplikacji internetowych i mobilnych. Grupa robocza OAuth aktywnie aktualizuje i ulepsza OAuth 2.1, aby upewnić się, że spełnia najnowsze standardy bezpieczeństwa i najlepsze praktyki. Najnowszy projekt, OAuth 2.1 11, został wydany w maju 2024 roku, co oznacza istotny postęp w kierunku finalizacji. W związku z nadchodzącą szeroką adopcją zdecydowanie zalecamy, aby wszyscy przestrzegali najlepszych praktyk opisanych w OAuth 2.1, aby wzmocnić bezpieczeństwo i poprawić doświadczenia użytkownika.