Dlaczego powinieneś wycofać typ potwierdzenia Resource Owner Password Credentials (ROPC)

Wprowadzenie#

Typ potwierdzenia Resource Owner Password Credentials (ROPC), znany również jako potwierdzenie hasła, to przepływ OAuth 2.0, który pozwala aplikacji wymienić nazwę użytkownika i hasło na token dostępu. Został on po raz pierwszy wprowadzony w specyfikacji OAuth 2.0 jako sposób wsparcia przestarzałych aplikacji, takich jak HTTP basic authentication lub starsze aplikacje natywne, które nie mogły korzystać z bardziej bezpiecznych przepływów opartych na tokenach OAuth.

Jednak typ potwierdzenia ROPC niesie ze sobą kilka zagrożeń dla bezpieczeństwa i został oznaczony jako NIE MOŻE być używany w najlepszych praktykach bezpieczeństwa OAuth 2.0.

Ostatnio otrzymaliśmy kilka pytań od naszych klientów dotyczących wskazówek lub wsparcia w implementacji typu potwierdzenia ROPC. W tym artykule wyjaśnimy, dlaczego powinieneś unikać korzystania z typu potwierdzenia ROPC, zwłaszcza w nowych aplikacjach.

Typ potwierdzenia ROPC vs. przepływ kodu autoryzacyjnego#

Jak działa typ potwierdzenia ROPC#

Typ potwierdzenia ROPC to prosty przepływ, który wymienia nazwę użytkownika i hasło na token dostępu. Aplikacja klienta zbiera bezpośrednio dane uwierzytelniające użytkownika i wysyła je bezpośrednio do serwera autoryzacyjnego. Serwer autoryzacyjny weryfikuje dane uwierzytelniające i wydaje token dostępu aplikacji klienta.

Jak działa przepływ kodu autoryzacyjnego#

W przeciwieństwie do tego, przepływ kodu autoryzacyjnego to zalecany przepływ OAuth 2.0 dla aplikacji webowych. Obejmuje on kilka kroków i przekierowania między aplikacją klienta, serwerem autoryzacyjnym oraz przeglądarką użytkownika. Przepływ kodu autoryzacyjnego jest bardziej bezpieczny, ponieważ nie naraża danych uwierzytelniających użytkownika na aplikację klienta.

Główna różnica między typem potwierdzenia ROPC a przepływem kodu autoryzacyjnego polega na tym, że ROPC naraża dane uwierzytelniające użytkownika na aplikację klienta, podczas gdy przepływ kodu autoryzacyjnego tego nie robi. Dane uwierzytelniające użytkownika powinny być poufnie przechowywane w serwerze autoryzacyjnym. Za każdym razem, gdy aplikacja klienta żąda zasobu w imieniu użytkownika, powinna przekierować użytkownika do serwera autoryzacyjnego w celu uwierzytelnienia i autoryzacji aplikacji klienta. Zapewnia to minimalną ilość danych autoryzacyjnych po stronie aplikacji klienta.

Zagrożenia bezpieczeństwa związane z typem potwierdzenia ROPC#

1. Narażenie danych uwierzytelniających użytkownika#

Jak wspomnieliśmy wcześniej, typ potwierdzenia ROPC naraża dane uwierzytelniające użytkownika na aplikację klienta. Jest to poważne zagrożenie bezpieczeństwa, ponieważ aplikacja klienta może przechowywać lub rejestrować dane uwierzytelniające użytkownika i ponownie autoryzować się bez wiedzy użytkownika.

Zwłaszcza w przypadku publicznej aplikacji klienta, takiej jak aplikacja mobilna lub aplikacja jednoskładnikowa, aplikacja klienta może zostać łatwo zainfekowana lub poddana inżynierii odwrotnej, aby wyodrębnić dane uwierzytelniające użytkownika. Ani aplikacja mobilna, ani aplikacja jednoskładnikowa działająca w przeglądarce użytkownika nie mogą przechowywać tajemnic w sposób poufny. Dlatego nie mogą one uwierzytelnić użytkownika bez narażania jego danych uwierzytelniających.

Nawet jeśli właściciel zasobu ma zaufany związek z aplikacją klienta, aplikacja klienta pełni rolę pośrednika w całym procesie uwierzytelniania i może zostać kompromitowana przez innego złośliwego aktora. Złośliwy aktor może ukraść dane uwierzytelniające użytkownika i podszywać się pod użytkownika, aby uzyskać dostęp do jego zasobów.

Istnieje wiele sposobów kradzieży danych uwierzytelniających użytkownika, w zależności od postawy bezpieczeństwa aplikacji klienta, takich jak keyloggery, ataki phishingowe lub złośliwe oprogramowanie. Nie wspominając o tym, że dane uwierzytelniające aplikacji klienta są przesyłane przez sieć przy każdym żądaniu autoryzacyjnym, co dodatkowo zwiększa ryzyko przechwycenia danych uwierzytelniających.

Wyobraź sobie, że masz wiele aplikacji, które korzystają z typu potwierdzenia ROPC. Potencjalne ryzyko narażenia danych uwierzytelniających jest wtedy zwielokrotnione.

2. ROPC nie obsługuje zgody użytkownika#

Typ potwierdzenia ROPC nie obsługuje zgody użytkownika. Kiedy aplikacja klienta bezpośrednio zbiera dane uwierzytelniające użytkownika, użytkownik nie ma możliwości przeglądania i zatwierdzania dostępu aplikacji klienta do swoich zasobów. Jest to naruszenie prywatności i zaufania użytkownika.

Użytkownicy powinni mieć prawo decydować, która aplikacja klienta może uzyskać dostęp do ich zasobów i na jak długo. Zwłaszcza w przypadku aplikacji trzecich, mechanizm zgody użytkownika jest niezbędny do ochrony danych właściciela zasobu i jest kluczowy dla przestrzegania przepisów o ochronie danych, takich jak RODO.

3. ROPC nie obsługuje wieloczynnikowego uwierzytelniania#

Wieloczynnikowe uwierzytelnianie (MFA) to implementacja zabezpieczeń, która wymaga od użytkownika dostarczenia dwóch lub więcej czynników weryfikacyjnych, aby uzyskać dostęp do swoich zasobów. Dodaje to dodatkową warstwę bezpieczeństwa do procesu uwierzytelniania. Typ potwierdzenia ROPC nie obsługuje MFA. Zamiast tego ogranicza proces uwierzytelniania do jednego czynnika, a żądanie tokenu opiera się wyłącznie na danych uwierzytelniających użytkownika. Niemożliwe jest wdrożenie mechanizmów uwierzytelniania opartych na wyzwaniach, takich jak SMS OTP, email OTP czy WebAuthn, z typem potwierdzenia ROPC.

ROPC jest niekompatybilny z nowoczesnymi aplikacjami#

Typ potwierdzenia ROPC został zaprojektowany, aby wspierać starsze aplikacje, które nie mogą obsługiwać nowoczesnych systemów IAM, takich jak Single Sign-On (SSO) lub tożsamości federacyjne.

1. ROPC jest niekompatybilny z SSO#

Single Sign-On (SSO) to nowoczesna architektura uwierzytelniania, która pozwala użytkownikom na jednokrotne zalogowanie się i bezproblemowy dostęp do wielu aplikacji.

Centralizowany IdP odgrywa kluczową rolę w architekturze SSO. Zarządza on sesjami uwierzytelnienia użytkownika i wydaje tokeny dla aplikacji klienta. Aplikacje klienta nie muszą bezpośrednio zbierać danych uwierzytelniających użytkownika, a dane uwierzytelniające użytkownika są przechowywane poufnie w IdP.

Typ potwierdzenia ROPC nie obsługuje SSO. Wymaga on, aby aplikacja klienta bezpośrednio zbierała dane uwierzytelniające użytkownika, co narusza architekturę SSO. Jest on niekompatybilny z nowoczesnymi systemami SSO, takimi jak OpenID Connect (OIDC) czy SAML.

2. ROPC jest niekompatybilny z federacyjnymi tożsamościami#

Podobnie jak w architekturze SSO, tożsamości federacyjne pozwalają użytkownikom na korzystanie z istniejącej tożsamości do uzyskiwania dostępu do wielu aplikacji trzecich. Użytkownik może połączyć wiele kont społecznościowych, takich jak Google, Facebook czy Twitter, z centralizowanym IdP i korzystać z tych kont społecznościowych do uwierzytelniania z aplikacjami klienta. Wszystkie tożsamości federacyjne są zarządzane przez IdP i aplikacje klienta nie są świadome szczegółów uwierzytelniania użytkownika.

Typ potwierdzenia ROPC, z drugiej strony, wymaga, aby aplikacja klienta bezpośrednio zbierała dane uwierzytelniające użytkownika. Ogranicza to zdolność aplikacji klienta do obsługi tożsamości federacyjnych i naraża dane tożsamości użytkownika na aplikację klienta.

Wniosek#

Typ potwierdzenia Resource Owner Password Credentials (ROPC) to przestarzały przepływ OAuth 2.0, który niesie ze sobą znaczące zagrożenia dla bezpieczeństwa i powinien zostać wycofany. Naraża on dane uwierzytelniające użytkownika na aplikację klienta i nie obsługuje nowoczesnych mechanizmów zabezpieczeń, takich jak MFA czy SSO. Zdecydowanie zalecamy unikanie korzystania z typu potwierdzenia ROPC w swoich aplikacjach. Jeżeli masz starzejące się systemy uwierzytelniania, które opierają się na typie potwierdzenia ROPC, rozważ migrację do bardziej bezpiecznych przepływów OAuth 2.0, takich jak przepływ kodu autoryzacyjnego lub przepływ potwierdzenia klienta.

Skontaktuj się z nami, jeśli potrzebujesz pomocy we wdrożeniu bezpiecznej usługi uwierzytelniania i autoryzacji użytkowników do swoich aplikacji lub migracji z przestarzałego systemu uwierzytelniania opartego na hasłach na bardziej bezpieczny przepływ OAuth 2.0. Jesteśmy tutaj, aby pomóc Ci budować bezpieczne i nowoczesne aplikacje.