Dlaczego powinieneś używać przepływu kodu autoryzacyjnego zamiast przepływu implicit?

Przepływ kodu autoryzacyjnego i przepływ implicit to typy przyznawania protokołu OAuth 2.0. Są one używane do uzyskiwania tokenu dostępu z serwera autoryzacyjnego. Dzięki tokenom dostępu aplikacje lub usługi mogą wykonywać określone operacje i uzyskiwać dostęp do określonych zasobów w imieniu użytkowników.

Co to jest OAuth?#

Kiedy mówimy o OAuth, zazwyczaj odnosimy się do OAuth 2.0, znanego jako "Open Authorization", który jest ustalonym protokołem umożliwiającym stronom internetowym lub aplikacjom wykorzystywanie zasobów z innych usług sieciowych w imieniu użytkownika. Zastąpił on OAuth 1.0 w 2012 roku i od tego czasu stał się powszechnie akceptowanym standardem autoryzacji cyfrowej. OAuth 2.0 ułatwia kontrolowany dostęp, pozwalając aplikacjom klienckim na uzyskiwanie określonych uprawnień do interakcji z zasobami reprezentującymi użytkownika, wszystko to bez ujawniania danych logowania użytkownika.

Chociaż przede wszystkim wykorzystywany w środowiskach sieciowych, framework OAuth 2.0 rozszerza również swoje działanie na różne formy klientów. Obejmuje to aplikacje przeglądarkowe, aplikacje internetowe po stronie serwera, aplikacje natywne lub mobilne, a nawet połączone urządzenia, szczegółowo opisując podejście do zarządzania delegowanym dostępem w tych platformach.

Protokół OAuth 2.0 definiuje cztery główne typy przyznawania, każdy z nich zaprojektowany do różnych scenariuszy:

• Kod autoryzacyjny: Idealny dla aplikacji po stronie serwera, ten przepływ polega na przekierowaniu użytkownika do serwera autoryzacyjnego w celu zalogowania się. Po uwierzytelnieniu użytkownik jest przekierowywany z powrotem do aplikacji z kodem autoryzacyjnym, który następnie jest wymieniany na token dostępu.
• Implicit: Przeznaczony dla aplikacji po stronie klienta lub działających w przeglądarce (takich jak aplikacje jednostronicowe), gdzie token dostępu jest zwracany natychmiastowo bez potrzeby dodatkowego kroku wymiany kodu autoryzacyjnego.
• Poświadczenia hasła właściciela zasobów: Ten typ pozwala aplikacji klienckiej bezpośrednio żądać i otrzymywać token dostępu poprzez przekazywanie poświadczeń użytkownika (nazwa użytkownika i hasło). Jest mniej powszechny z powodu obaw związanych z bezpieczeństwem i zwykle używany z aplikacjami wysoko zaufanymi.
• Poświadczenia klienta: Używane do komunikacji serwer-serwer, gdzie aplikacja sama jest klientem. Polega na uwierzytelnieniu aplikacji w serwerze autoryzacyjnym i żądaniu tokenu dostępu, aby uzyskać dostęp do swoich zasobów lub tych z innej usługi.

Przyjrzyjmy się dwóm najczęściej używanym typom przyznawania, przepływowi przyznawania kodu autoryzacyjnego i przepływowi przyznawania implicit, ponieważ wielu deweloperów nie jest pewnych, jaki typ przyznawania wybrać.

Jak działa przepływ implicit?#

Przepływ implicit w OAuth 2.0 został opracowany około dekadę temu, w czasach, gdy funkcjonalności przeglądarek były zupełnie inne niż dzisiaj. Ten przepływ powstał głównie z powodu historycznych ograniczeń przeglądarek, gdzie JavaScript mógł wysyłać żądania tylko do serwera, z którego została załadowana strona. Standardowy przepływ kodu autoryzacyjnego OAuth jednak wymaga POST request do punktu końcowego tokenu serwera OAuth, zazwyczaj hostowanego na innej domenie niż aplikacja. To ograniczenie sprawiło, że nie było możliwe zaimplementowanie tego przepływu wyłącznie w JavaScript. Przepływ implicit unikał tego, eliminując POST request i zamiast tego dostarczając token dostępu bezpośrednio w procesie przekierowania.

Obecnie, przy powszechnym zastosowaniu Cross-Origin Resource Sharing (CORS) w przeglądarkach, ograniczenia, które doprowadziły do powstania przepływu implicit, nie są już istotne. CORS pozwala JavaScript wysyłać żądania do serwerów w różnych domenach, o ile pozwalają one na takie działania. To udoskonalenie czyni przepływ kodu autoryzacyjnego możliwym do użycia w aplikacjach JavaScript.

Warto zauważyć, że przepływ implicit zawsze był uważany za mniej bezpieczną alternatywę dla przepływu kodu autoryzacyjnego. Na przykład, specyfikacja OAuth nie obsługuje zwracania tokenów odświeżających w przepływie implicit z powodu obaw związanych z bezpieczeństwem.

Jak działa przepływ kodu autoryzacyjnego?#

Obecnie możliwe jest użycie przepływu kodu autoryzacyjnego z przeglądarek, ale nadal musimy rozwiązać kwestię związaną z aplikacjami JavaScript. Tradycyjnie, przepływ kodu autoryzacyjnego używa tajemnicy klienta do wymiany kodu autoryzacyjnego na token dostępu, której nie można uwzględnić w aplikacjach JavaScript, chcąc utrzymać ją w tajemnicy.

Problem ten został rozwiązany przez rozszerzenie Proof Key for Code Exchange (PKCE) (przeczytaj ten blog, aby dowiedzieć się więcej szczegółów o PKCE i jak może chronić przepływ uwierzytelniania). Przepływ kodu autoryzacyjnego z PKCE dodaje dodatkowe kroki, pozwalające na zabezpieczenie kodu autoryzacyjnego, czyniąc go bezużytecznym nawet jeśli zostanie skradziony podczas procesu przekierowania.

Wady przepływu implicit#

Z powyższego wprowadzenia widzimy dwa znaczące zagrożenia bezpieczeństwa związane z przepływem implicit:

1. Jednym z powodów, dla których przepływ implicit jest mniej bezpieczny niż przepływ kodu autoryzacyjnego, jest brak uwierzytelniania klienta. W przeciwieństwie do klientów poufnych, publiczni klienci, tacy jak aplikacje JavaScript uruchamiane w przeglądarce, nie mogą chronić żadnych tajemnic. W związku z tym wymaganie od publicznych klientów uwierzytelnienia nie ma sensu, ponieważ dane uwierzytelniające klienta mogą być widoczne poprzez badanie kodu źródłowego w przeglądarce. W przypadkach, gdy nie jest wymagane uwierzytelnienie klienta, każda aplikacja może udawać tego klienta, o ile zna jego identyfikator.
2. Przepływ implicit musi przekazywać token dostępu przez przekierowanie URL, umożliwiając inne rodzaje ataków. Na przykład, jeśli token znajduje się w części zapytania URL, przeglądarka nie może zapobiec przypadkowemu zapisaniu tokenu dostępu do historii. Ponadto nic nie wpływa na przesyłanie pełnego URL zawierającego token do innych serwerów.

Czy przepływ kodu autoryzacyjnego może wyeliminować problemy bezpieczeństwa przepływu implicit?#

Odpowiedź brzmi TAK:

1. Przepływ kodu autoryzacyjnego używa kodu autoryzacyjnego uzyskanego poprzez uwierzytelnienie użytkownika wraz z poświadczeniami klienta do uzyskania tokenu dostępu poprzez żądania tokenu, proces chroniony przez szyfrowanie połączenia HTTPS.
2. Jak wspomniano wcześniej, wprowadzając mechanizm PKCE, możemy zapewnić, że nawet jeśli złośliwe aplikacje lub strony przechwycą kod autoryzacyjny i poświadczenia klienta, nie mogą uzyskać tokenu dostępu, ponieważ nie mają poprawnego weryfikatora kodu.

Jeśli obecnie używasz przepływu implicit w swoim biznesie, przeniesienie się na przepływ kodu autoryzacyjnego z PKCE może zapewnić lepsze bezpieczeństwo zarówno dla ciebie, jak i twoich użytkowników. Rozumiemy, że migracja i zarządzanie systemem tożsamości może być uciążliwa i kosztowna, dlatego stworzyliśmy Logto - prosty, łatwy w użyciu, ale potężny narzędzie do zarządzania tożsamościami. Logto wykorzystuje przepływ kodu autoryzacyjnego zintegrowany z PKCE w procesie logowania użytkownika, oferując najwyższy poziom bezpieczeństwa dla użytkowników.