Przepływ implicytny a Przepływ autoryzacji: Dlaczego przepływ implicytny jest martwy?

Przepływ autoryzacji i Przepływ implicytny to jedne z najczęściej używanych typów zezwoleń w OAuth 2.0, umożliwiając bezpieczną i efektywną autoryzację użytkowników w aplikacjach internetowych. Oba przepływy implementują proces autoryzacji, który pozwala użytkownikom przyznać dostęp do aplikacji bez bezpośredniego ujawniania ich danych uwierzytelniających. Przepływ implicytny został pierwotnie opracowany w celu rozwiązania ograniczeń przeglądarek, ale wraz z pojawieniem się nowoczesnych technologii webowych przepływ autoryzacji stał się preferowanym wyborem dla wielu deweloperów ze względu na swoje zaawansowane funkcje bezpieczeństwa.

W tym artykule porównamy różnice między tymi dwoma typami zezwoleń i wyjaśnimy, dlaczego należy je unikać na rzecz przepływu autoryzacji.

Co to jest OAuth 2.0?#

Zanim zagłębimy się w szczegóły tych dwóch typów zezwoleń, najpierw spróbujmy zrozumieć, czym jest OAuth 2.0 i dlaczego jest niezbędny dla współczesnych aplikacji internetowych.

Mówiąc o OAuth, zazwyczaj odnosimy się do OAuth 2.0, znanego jako „Open Authorization” (Otwarta Autoryzacja), uznawanego protokołu umożliwiającego stronom internetowym lub aplikacjom korzystanie z zasobów z innych usług internetowych w imieniu użytkownika. Zastąpił OAuth 1.0 w 2012 roku i od tego czasu stał się powszechnie akceptowanym standardem cyfrowej autoryzacji. OAuth 2.0 został zaprojektowany w celu zapewnienia kontrolowanego dostępu do użytkowników, umożliwiając aplikacjom klienckim interakcję z zasobami reprezentującymi użytkownika, wszystko to bez ujawniania szczegółów loginu użytkownika.

Chociaż głównie wykorzystywane w środowiskach internetowych, struktura OAuth 2.0 rozciąga się również na różnorodne formy klienta. Obejmuje to aplikacje oparte na przeglądarce, aplikacje internetowe po stronie serwera, aplikacje native lub mobilne, a nawet połączone urządzenia, szczegółowo opisując podejście do zarządzania delegowanym dostępem na różnych platformach. Wprowadza koncepcję „typów zezwoleń”, aby zdefiniować proces autoryzacji między aplikacją kliencką, użytkownikiem, a serwerem autoryzacji. Te typy zezwoleń są wykorzystywane do określenia, jak aplikacja kliencka może uzyskać token dostępu do zasobów użytkownika. Najczęstsze typy zezwoleń w OAuth 2.0 to:

• Kod autoryzacji: Idealny dla wszystkich typów aplikacji, zwłaszcza aplikacji internetowych po stronie serwera, gdzie aplikacja kliencka może wymienić kod autoryzacyjny na token dostępu i bezpiecznie zarządzać tokenami.
• Implicytny: Uproszczony przepływ, zaprojektowany dla aplikacji przeglądarkowych, bez bezpiecznej komponenty serwera. Został stworzony, aby szybko dostarczać tokeny do aplikacji klienckich. Ale obecnie jest w dużej mierze przestarzały z powodu problemów z bezpieczeństwem.
• Dane logowania właściciela zasobu: Ten typ pozwala aplikacji klienckiej bezpośrednio żądać i otrzymywać token dostępu przez przesłanie danych uwierzytelniających użytkownika (login i hasło). Z uwagi na to, że aplikacja kliencka ma bezpośredni dostęp do danych uwierzytelniających użytkownika, ten typ zezwolenia również jest uważany za przestarzały i należy go unikać w każdych okolicznościach.
• Dane logowania klienta: Używane do komunikacji maszyna-do-maszyny, gdzie aplikacja sama jest klientem. Polega na uwierzytelnieniu się aplikacji przy serwerze autoryzacyjnym i zażądaniu tokenu dostępu do dostępu do własnych zasobów lub tych z innej usługi.

Czym jest przepływ implicytny?#

Przepływ implicytny to uproszczony przepływ OAuth 2.0, w którym token dostępu zwracany jest bezpośrednio do klienta w URI przekierowania, bez dodatkowego kroku wymiany kodu autoryzacyjnego na token. Pierwotnie został zaprojektowany dla aplikacji internetowych, które nie mogły wykonywać żądań po stronie serwera na punkt końcowy tokena z powodu ograniczeń przeglądarki.

Jak działa przepływ implicytny?#

1. Użytkownik klika przycisk lub link w aplikacji klienckiej, aby rozpocząć proces uwierzytelniania.
2. Aplikacja kliencka przekierowuje użytkownika do serwera autoryzacji w celu uwierzytelnienia, w tym z zakresem dostępu.
3. Serwer autoryzacji prosi użytkownika o zalogowanie się i udzielenie zgody aplikacji klienckiej.
4. Po pomyślnym uwierzytelnieniu i autoryzacji serwer autoryzacji przekierowuje przeglądarkę użytkownika z powrotem do określonego URL przekierowania klienta, z tokenem dostępu zawartym w URL fragment.
5. Aplikacja kliencka pobiera token dostępu z fragmentu URL i używa go do uzyskania dostępu do zasobów użytkownika na serwerze zasobów.

Zagrożenia bezpieczeństwa związane z przepływem implicytnym#

Przepływ implicytny ma kilka luk w bezpieczeństwie:

• Ekspozycja tokena: Token dostępu jest bezpośrednio zwrócony do klienta w URL fragment, co może zostać łatwo przechwycone przez złośliwe podmioty. To naraża token dostępu na potencjalną kradzież i nadużycie.
• Ataki CSRF: Przepływ implicytny jest podatny na ataki Cross-Site Request Forgery (CSRF), gdzie złośliwe strony internetowe mogą nakłonić użytkowników do nieautoryzowanego dostępu do ich kont.

Z uwagi na te problemy z bezpieczeństwem, przepływ implicytny nie jest już zalecany dla nowoczesnych aplikacji internetowych. Zamiast niego przepływ autoryzacji z PKCE (Proof Key for Code Exchange) jest preferowanym wyborem dla bezpiecznej autoryzacji użytkownika.

Czym jest przepływ autoryzacji?#

Z kolei przepływ autoryzacji to bardziej bezpieczny przepływ OAuth 2.0, który dzieli proces autoryzacji na dwa kroki: aplikacja kliencka najpierw uzyskuje kod autoryzacyjny od serwera autoryzacji, a następnie wymienia kod na token dostępu. Ten przepływ został początkowo zaprojektowany dla aplikacji internetowych po stronie serwera, które mogą bezpiecznie przechowywać dane logowania klienta i zarządzać tokenami dostępu. Wraz z wprowadzeniem rozszerzenia PKCE przepływ autoryzacji może być teraz używany także w aplikacjach przeglądarkowych.

Jak działa przepływ autoryzacji dla prywatnych klientów z komponentem po stronie serwera?#

1. Użytkownik klika przycisk lub link w aplikacji klienckiej, aby rozpocząć proces uwierzytelniania.
2. Aplikacja kliencka przekierowuje użytkownika do serwera autoryzacji w celu uwierzytelnienia z zakładanym zakresem dostępu.
3. Serwer autoryzacji prosi użytkownika o zalogowanie się i udzielenie zgody aplikacji klienckiej.
4. Po pomyślnym uwierzytelnieniu i autoryzacji serwer autoryzacji zwraca kod autoryzacyjny do klienta.
5. Aplikacja kliencka bezpiecznie wymienia kod autoryzacyjny na token dostępu, wykonując żądanie serwer-serwer do punktu końcowego tokena, używając swoich danych logowania klienta.
6. Serwer autoryzacji weryfikuje kod autoryzacyjny i dane logowania klienta, zwracając token dostępu do klienta.
7. Aplikacja kliencka używa tokena dostępu do uzyskania dostępu do zasobów użytkownika na serwerze zasobów.

Jak działa przepływ autoryzacji dla publicznych klientów z PKCE?#

1. Użytkownik klika przycisk lub link w aplikacji klienckiej, aby rozpocząć proces uwierzytelniania.
2. Aplikacja kliencka generuje weryfikator kodu i wyzwanie kodowe.
3. Aplikacja kliencka przekierowuje użytkownika do serwera autoryzacji w celu uwierzytelnienia z wyzwaniem kodowym.
4. Serwer autoryzacji przechowuje wyzwanie kodowe do późniejszej weryfikacji.
5. Użytkownik uwierzytelnia się i zatwierdza dostęp do aplikacji klienckiej.
6. Serwer autoryzacji zwraca kod autoryzacyjny do klienta.
7. Aplikacja kliencka wymienia kod autoryzacyjny na token dostępu, wykonując żądanie serwer-serwer do punktu końcowego tokena za pomocą weryfikatora kodu.
8. Serwer autoryzacji weryfikuje kod autoryzacyjny i weryfikator kodu względem przechowywanego wyzwania kodowego.
9. Serwer autoryzacji zwraca token dostępu do klienta.
10. Aplikacja kliencka używa tokena dostępu do uzyskania dostępu do zasobów użytkownika na serwerze zasobów.

Dowiedz się więcej o PKCE przepływie.

Przepływ implicytny vs. Przepływ autoryzacji#

Czy przepływ autoryzacji może wyeliminować problemy bezpieczeństwa przepływu implicytnego?#

Odpowiedź brzmi TAK:

Przepływ autoryzacji wprowadza dodatkowy krok wymiany kodu autoryzacyjnego na token dostępu, co znacznie zmniejsza ryzyko ujawnienia tokena.

• Dla prywatnych klientów z bezpiecznym komponentem po stronie serwera, aplikacja kliencka może bezpiecznie wymienić kod autoryzacyjny na token dostępu za pomocą swoich danych logowania klienta.
• Dla publicznych klientów bez bezpiecznego komponentu po stronie serwera, rozszerzenie PKCE może być używane do ochrony procesu wymiany kodu autoryzacyjnego.

Jeśli obecnie używasz przepływu implicytnego w swojej firmie, przejście na przepływ autoryzacji z PKCE może zapewnić lepsze bezpieczeństwo zarówno Tobie, jak i Twoim użytkownikom. Rozumiemy, że migracja i zarządzanie systemem tożsamości może być uciążliwe i kosztowne, ale korzyści płynące z ulepszonego bezpieczeństwa i zgodności są warte wysiłku.