Odpowiedź na twoje pytanie może być na poziomie kodu, protokołu lub architektury. Spróbuję podsumować tutaj większość problemów na poziomie protokołu, ponieważ jest to zwykle krytyczne w analizie zalet i wad. Należy pamiętać, że OAuth2 to znacznie więcej niż poświadczenia hasła właściciela zasobu, które zgodnie ze specyfikacją istnieją z „starszych lub migracyjnych powodów”, są uważane za „wyższe ryzyko niż inne typy dotacji”, a specyfikacja wyraźnie stwierdza, że klienci i serwery autoryzacji „POWINIEN zminimalizować użycie tego rodzaju grantu i w miarę możliwości wykorzystywać inne typy grantu”.
Nadal istnieje wiele zalet korzystania z ROPC w porównaniu z podstawowym uwierzytelnianiem, ale zanim do tego przejdziemy, zrozumiemy podstawową różnicę protokołu między OAuth2 i podstawowym uwierzytelnianiem. Proszę o wyrozumiałość, gdy je wyjaśnię i przybędę do ROPC później.
Przepływy uwierzytelnienia użytkownika
Istnieją cztery role zdefiniowane w specyfikacji OAuth2. Przykładami są:
- Właściciel zasobu: użytkownik, który ma dostęp do niektórych zasobów, np. W twoim przypadku różni użytkownicy mogą mieć inny poziom dostępu do interfejsu API REST;
- Klient: zwykle aplikacja, z której korzysta użytkownik, i potrzebuje dostępu do zasobu, aby świadczyć usługi na rzecz użytkownika;
- Serwer zasobów: interfejs API REST w twoim przypadku; i
- Serwer autoryzacji: serwer, na którym prezentowane są poświadczenia użytkownika i który będzie uwierzytelniał użytkownika.
Po uruchomieniu aplikacji klienckiej przyznaje się dostęp do zasobów na podstawie użytkownika. Jeśli użytkownik ma uprawnienia administratora, zasoby i operacje dostępne dla użytkownika w interfejsie API REST mogą być czymś znacznie większym niż użytkownik bez uprawnień administratora.
OAuth2 umożliwia także korzystanie z jednego serwera autoryzacji z wieloma klientami i wieloma zasobami. Na przykład serwer zasobów może akceptować uwierzytelnianie użytkownika za pomocą Facebooka (który w takim przypadku może działać jako serwer autoryzacji). Kiedy więc użytkownik uruchomi aplikację (tj. Klienta), wysyła użytkownika do Facebooka. Użytkownik wpisuje swoje dane uwierzytelniające na Facebooku, a klient otrzymuje „token”, który może przedstawić serwerowi zasobów. Serwer zasobów patrzy na token i akceptuje go po sprawdzeniu, że Facebook faktycznie go wystawił i umożliwia użytkownikowi dostęp do zasobu. W takim przypadku klient nigdy nie widzi poświadczeń użytkownika (tj. Poświadczeń na Facebooku).
Załóżmy jednak, że zarządzasz tożsamościami użytkownika (i masz serwer autoryzacji) zamiast Facebooka, który już udziela tokenów klientowi. Załóżmy teraz, że masz partnera i chcesz zezwolić jego aplikacji (tj. Klientowi) na dostęp do interfejsu API REST. W przypadku podstawowego uwierzytelnienia (lub nawet ROPC) użytkownik poda poświadczenia temu klientowi, który wyśle je do serwera autoryzacji. Serwer autoryzacji dostarczy token, którego klient może użyć do uzyskania dostępu do zasobów. Niestety oznacza to, że poświadczenia użytkownika są teraz widoczne również dla tego klienta. Jednak nie chcesz, aby aplikacja partnera (która mogła być spoza organizacji) nawet znała hasło użytkownika. To teraz problem bezpieczeństwa. Aby osiągnąć ten cel,
Zatem w przypadku OAuth2 idealnie byłoby nie używać ROPC w takich przypadkach, a raczej użyć innego, takiego jak przepływ kodu autoryzacji. Chroni to każdą aplikację przed znajomością poświadczeń użytkownika, które są prezentowane tylko serwerowi autoryzacji. W ten sposób poświadczenia użytkownika nie są wyciekane. Te same problemy dotyczą podstawowego uwierzytelnienia, ale w następnej sekcji wyjaśnię, w jaki sposób ROPC jest jeszcze lepszy, ponieważ poświadczenia użytkownika nadal nie muszą być przechowywane przez klienta w ROPC, aby klienci mieli stały dostęp.
Pamiętaj, że gdy użytkownik przejdzie do serwera autoryzacji, serwer autoryzacji może również poprosić użytkownika o potwierdzenie, że chce zezwolić klientowi na dostęp do zasobów w jego imieniu, czy też nie. Dlatego nazywa się to serwerem autoryzacji, ponieważ proces autoryzacji klienta do dostępu do zasobów jest związany z tym procesem. Jeśli użytkownik nie autoryzuje klienta, nie uzyska dostępu do zasobów. Podobnie, jeśli sam użytkownik nie ma dostępu do zasobów, serwer autoryzacji może nadal odmówić dostępu i nie wydać tokena.
W podstawowym uwierzytelnianiu nawet serwer autoryzacji i serwer zasobów są połączone w jedną całość. W związku z tym serwer zasobów chce autoryzować użytkownika, więc prosi o poświadczenia od klienta. Klient dostarcza poświadczenia, które są używane przez serwer zasobów do uwierzytelnienia użytkownika. Oznacza to, że wiele serwerów zasobów będzie zasadniczo wymagało poświadczeń od użytkownika.
Wydanie tokena
Klienci pobierają tokeny z serwera autoryzacji, przechowują je i używają do uzyskiwania dostępu do zasobów (więcej szczegółów na temat samych tokenów poniżej). Klienci nigdy nie znają hasła użytkownika (w przepływach innych niż ROPC) i nie muszą go przechowywać. W ROPC, chociaż klienci znają hasło użytkownika, nadal nie muszą go przechowywać, ponieważ używają tych tokenów do uzyskiwania dostępu do zasobów. Natomiast w przypadku podstawowego uwierzytelniania, jeśli klient nie chce, aby użytkownik podawał poświadczenia w każdej sesji, wówczas musi przechowywać hasło użytkownika, aby móc je podać następnym razem. Jest to poważna wada korzystania z podstawowego uwierzytelniania, chyba że klient jest tylko aplikacją internetową, w którym to przypadku pliki cookie mogą rozwiązać niektóre z tych problemów. W przypadku aplikacji natywnych zazwyczaj nie jest to możliwe.
Istnieje inny aspekt OAuth2, związany z tym, jak tokeny są wydawane i działają. Gdy użytkownik dostarczy dane uwierzytelniające do serwera autoryzacji (nawet w ROPC), serwer autoryzacji może nadać jeden lub więcej z dwóch typów tokenów: 1) token dostępu i 2) token odświeżania.
Tokeny dostępu są wysyłane do serwera zasobów, który zapewni dostęp do zasobów po ich sprawdzeniu, i zazwyczaj mają krótki okres użytkowania, np. 1 godz. Tokeny odświeżające są wysyłane do serwera autoryzacji przez klienta, aby uzyskać kolejny token dostępu, gdy wygasa, i zwykle mają długi okres użytkowania (np. Kilka dni do miesięcy lub nawet lat).
Gdy klient udostępnia token dostępu do serwera zasobów, patrzy na token, a po sprawdzeniu poprawności przegląda token, aby ustalić, czy zezwolić na dostęp, czy nie. Tak długo, jak token dostępu jest ważny, klient może go używać. Załóżmy, że użytkownik zamyka aplikację i uruchamia ją następnego dnia, a token dostępu wygasł. Teraz klient wykona połączenie z serwerem autoryzacji i przedstawi token odświeżania, zakładając, że nie wygasł. Serwer autoryzacji, ponieważ już wydał token, weryfikuje go i może stwierdzić, że użytkownik nie musi ponownie podawać poświadczeń, a tym samym daje klientowi kolejny token dostępu. Klient ma teraz ponownie dostęp do serwera zasobów. W ten sposób zwykle aplikacje klienckie na Facebooku i Twitterze pytają o dane uwierzytelniające raz, a następnie nie wymagają od użytkownika ponownego podawania danych uwierzytelniających. Aplikacje te nigdy nie muszą znać poświadczeń użytkowników, a jednak mogą uzyskiwać dostęp do zasobów za każdym razem, gdy użytkownik uruchomi aplikację.
Teraz użytkownik może wejść na serwer autoryzacji (np. W swoim profilu użytkownika na Facebooku), zmienić hasło bez wpływu na aplikacje klienckie. Wszystkie będą nadal działać poprawnie. Jeśli użytkownik straci urządzenie, na którym miał już aplikację z tokenami odświeżania, może nakazać serwerowi autoryzacji (np. Facebookowi) „wylogowanie” z tych aplikacji, które serwer autoryzacji (tj. Facebook) wykona, nie honorując żadnego z istniejących odświeżyć tokeny i zmusić użytkownika do ponownego podania poświadczeń podczas próby uzyskania dostępu do zasobów za pośrednictwem tych aplikacji.
JWT to po prostu format tokena, który jest zwykle używany z OAuth2 i OpenID Connect. Metody podpisywania tokena i sprawdzania jego poprawności są również znormalizowane z bibliotekami dostępnymi dla nich zamiast z każdym serwerem zasobów wdrażającym jeszcze inne rozwiązanie. Zaletą jest zatem możliwość ponownego użycia sprawdzonego kodu, który jest nadal obsługiwany.
Wpływ na bezpieczeństwo
Uwierzytelnianie podstawowe będzie słabsze, gdy którykolwiek z powyższych scenariuszy będzie widoczny na zdjęciu. Istnieje również rozbudowany model zagrożeń dla OAuth2 dostępny dla programistów, którzy mogą wykorzystać zawarte w nim sugestie, aby uniknąć typowych luk w swoich implementacjach. Jeśli przejdziesz przez model zagrożenia, zobaczysz, że obejmuje on również wiele luk związanych z implementacją (takich jak otwarty readresator i CSRF). W tej odpowiedzi nie przeprowadziłem porównania tych z podstawowym uwierzytelnianiem.
Ostatnią ważną zaletą protokołu OAuth2 jest to, że protokół jest ustandaryzowany i honoruje go wiele serwerów autoryzacji, klientów i serwerów zasobów. Liczne biblioteki są dostępne dla programistów, które są utrzymywane, więc ponieważ w implementacjach wykryte zostaną problemy bezpieczeństwa, biblioteki są aktualizowane przy jednoczesnym zapewnieniu interoperacyjności.
Wniosek
Jeśli piszesz nową aplikację, IMO, idealnym rozwiązaniem byłoby uniknięcie zarówno podstawowego uwierzytelnienia, jak i ROPC ze względu na związane z nimi problemy. Jednak każda aplikacja ma inne potrzeby, harmonogramy, biegłość programistyczną itp., Więc decyzja jest podejmowana indywidualnie. Ale nawet jeśli nie potrzebujesz więcej niż podstawowego uwierzytelnienia, wybierając go, możesz zablokować się w architekturze, która może nie być łatwa do rozszerzenia (np. Jeśli będziesz mieć wiele serwerów w przyszłości, niekoniecznie będziesz chciał mieć użytkownik podaje poświadczenia każdemu z nich, a tylko raz przekazuje serwer autoryzacji, który może rozdawać tokeny itp.)
Zauważ, że nie odniosłem się do twojego komentarza na temat tego, w jaki sposób poświadczenia są przesyłane przewodowo, ponieważ można je zabezpieczyć za pomocą TLS lub podobnego protokołu lub dowodu posiadania itp. Jak ktoś już sugerował, kodowanie bazowe 64 to 0 zabezpieczeń, proszę nie dać się zwieść temu. Różnice wspomniane powyżej są zwykle na poziomie architektonicznym, dlatego skupiłem się na nich, ponieważ architektura jest najtrudniejsza do zmiany po wdrożeniu.
Azure Active Directory B2C Basic , usługa, nad którą pracuję, a która została niedawno wydana do publicznej wersji zapoznawczej, umożliwia aplikacjom zewnętrznym używanie AAD jako serwera autoryzacji z interoperacyjnością z serwisami społecznościowymi IDP (takimi jak Facebook, Google itp.). Umożliwia także użytkownikom tworzenie własnych kont zamiast korzystania z IDP społecznościowych, które można później wykorzystać do celów uwierzytelnienia. Istnieje również kilka innych podobnych usług (np. Inna, o której wiem, to auth0), z którego programiści mogą korzystać w celu całkowitego outsourcingu uwierzytelniania i zarządzania użytkownikami dla swoich aplikacji i zasobów. Te same cechy protokołów, o których wspomniałem powyżej, są używane przez programistów do rozdzielania serwera autoryzacji (AAD), zasobu (np. Ich interfejsów API REST), klienta (np. Ich aplikacji mobilnych) i użytkowników. Mam nadzieję, że to wyjaśnienie nieco pomoże.