Zarządzanie roszczeniami
Następnie musimy dokładnie przemyśleć kwestię roszczeń. Roszczenie to po prostu para nazwa/wartość osadzona w naszych tokenach dostępu i ID. Na przykład, możesz mieć roszczenie user_id lub email, aby kolejne aplikacje mogły ich używać do tworzenia profili lub podejmowania decyzji. Zagmatwaną częścią jest to, że specyfikacja OAuth Core nie wprowadza pojęcia roszczeń, ani nawet nie zawiera słowa roszczenie. Jest to użyteczne, ponieważ możemy zdefiniować, jakkolwiek potrzebujemy. Niestety, wyzwaniem jest to, że ludzie będą je definiować jakkolwiek będą tego potrzebować. Specyfikacja JWT (RFC 7519) wprowadza pojęcie i definiuje podstawową strukturę, ale nadal nie ustala żadnych konwencji dla nazw, struktur, itp.
Używanie OpenID Connect chroni nas dość mocno. Definiuje prosty zestaw roszczeń dla szczegółów użytkownika, takich jak nazwa, adres i podobne. Jeśli używamy tylko tych i ograniczamy dostęp do nich zgodnie z odpowiednimi zakresami, użytkownik wie, jakimi informacjami się dzieli, a aplikacje wiedzą, jak z nich korzystać.
Alternatywnie, gdy dodajemy dodatkowe roszczenia, naturalnym pragnieniem jest posiadanie unikalnego identyfikatora użytkownika. Jeśli się nad tym zastanawiamy, używamy ukrytego klucza głównego, który nie ma znaczenia poza naszym systemem. Jeśli nie jesteśmy ostrożni, może to być identyfikator klienta, numer pracownika, a nawet numer ubezpieczenia społecznego. Jest to ta sama sytuacja, w której Facebook zmaga się z konsekwencjami udostępniania zbyt wielu informacji o sieci użytkownika za pośrednictwem swojego API.
Musimy być rozważni i brać pod uwagę konsekwencje informacji, które umieszczamy w naszych tokenach. Nigdy nie powinniśmy umieszczać danych „na wszelki wypadek” i zamiast tego czekać na konkretne przypadki użycia, które zdecydujemy się wspierać. Wszystko inne jest ryzykowne w najlepszym przypadku i nieodpowiedzialne w najgorszym.
Typy grantów – kiedy i dlaczego
Podczas gdy przeskoczyłem od razu do zakresów i roszczeń, drugi najczęstszy błąd jest związany z konkretnymi typami grantów OAuth lub przepływami. Cztery typy grantów – Kod autoryzacji, Implicit, Hasło właściciela zasobu i Poświadczenie klienta – definiują jak aplikacja może pobrać tokeny z serwera OAuth i są używane w różnych przypadkach użycia.
Kod autoryzacji
Przepływ kodu autoryzacji jest najpotężniejszy i najbardziej bezpieczny domyślnie. Gdy aplikacja przekierowuje użytkownika do Dostawcy Tożsamości w celu uwierzytelnienia, IdP przekazuje z powrotem krótkotrwały, jednorazowy kod autoryzacji. Aplikacja używa kodu autoryzacyjnego do pobrania tokena dostępu.
Ważna część jest dwojaka: Po pierwsze, zanim użytkownik zobaczy kod autoryzacyjny, został on już zużyty i dlatego nie może być ponownie użyty. Po drugie, token dostępu jest przechowywany przez aplikację w backendzie. Zakładając, że aplikacja jest zbudowana bezpiecznie, złośliwy użytkownik musi znaleźć inny sposób, aby ją zaatakować.
Niestety, nie działa to w przypadku aplikacji po stronie klienta, takich jak wiele aplikacji Javascript lub większość aplikacji mobilnych, ponieważ sama aplikacja może zostać zaatakowana lub zdekompilowana w celu uzyskania wrażliwych informacji. Dlatego potrzebujemy innego podejścia.
Implicit
Przepływ Implicit został zaprojektowany specjalnie dla aplikacji mobilnych lub aplikacji Javascript po stronie klienta, gdzie wbudowane dane uwierzytelniające mogą być zagrożone. Mechanika jest prosta, aplikacja przekierowuje użytkownika do Dostawcy Tożsamości w celu uwierzytelnienia, IdP przekazuje z powrotem token(y), a aplikacja używa go zgodnie z zakresem jaki posiada.
Ponieważ jest całkiem prawdopodobne, że użytkownik może wejść w interakcję z tokenem(ami), ważne jest aby nasze przypadki użycia to odzwierciedlały. Jeśli mamy aplikację bankową, zezwolenie na zakres send_wire_transfers_to_russia może być złym pomysłem, chyba że mamy dodatkowe czynniki wbudowane w nasz proces uwierzytelniania, aby sprawdzić, czy właściwy użytkownik go używa. Następnym razem, gdy zgubisz swój telefon, docenisz to.
W rezultacie, jest to często używane w scenariuszach OpenID Connect, gdzie użytkownik chce dostarczyć informacje o profilu zaufanym stronie trzeciej, ale niekoniecznie dostęp lub uprawnienia do innych systemów. Ponieważ podstawowe koncepcje są takie same i implementacja wygląda bardzo podobnie, jest to większość korzyści za ten sam wysiłek.
Właściciel zasobu – hasło
W porównaniu do poprzednich typów grantów, Właściciel zasobu – hasło mnie denerwuje. Zarówno w przypadku przepływów Authorization Code jak i Implicit, aplikacja przekierowuje użytkownika do Identity Provider w celu podania nazwy użytkownika i hasła. W rezultacie aplikacja nigdy nie widzi ich danych uwierzytelniających. W przypadku przepływu Resource Owner Password, aplikacja sama akceptuje dane uwierzytelniające i przesyła je w imieniu użytkownika.
Jeśli aplikacja jest złośliwa lub po prostu słabo rozwinięta, może przechowywać te dane uwierzytelniające i narażać informacje o użytkowniku. Dlatego powinieneś używać tego rozwiązania tylko wtedy, gdy budujesz aplikacje dla użytkowników do interakcji ze starszymi systemami. Na przykład, bank może wdrożyć to dla wewnętrznego portalu pracowniczego.
Ale pamiętaj: Zasadniczo szkolisz użytkowników, aby umieszczali swoje dane uwierzytelniające w aplikacjach, którym mogą nie ufać, co jest w najlepszym przypadku złym nawykiem, a w każdym razie zagrożeniem bezpieczeństwa.
Poświadczenie klienta
Typ grantu Poświadczenie klienta jest przeznaczony wyłącznie do operacji backendowych między serwerami. Pomyśl o tym jak o nazwie użytkownika i haśle serwera. Koncepcyjnie, nie jest to dalekie od tego, jak twoja aplikacja łączy się z innymi systemami backendowymi, takimi jak baza danych lub Twilio. Zaletą jest to, że Twój dostawca OAuth może zwrócić informacje o konfiguracji lub inne szczegóły wewnątrz samego tokena.
Wreszcie, ponieważ nie ma tu użytkownika, nie wspiera OpenID Connect.
W zakończeniu
Choć cały ten post był o OAuth, prawdopodobnie zauważyłeś, że nie załączyłem żadnego kodu. Powód tego jest prosty: Decyzje projektowe są wciąż ważniejsze.
Jeśli twoje zakresy są zbyt szerokie lub twoje żądania zawierają wrażliwe informacje lub implementujesz niewłaściwy przepływ dla środowiska, najlepsze biblioteki na świecie nie ochronią cię. Informacje twoich użytkowników zostaną naruszone, twoje aplikacje będą podatne na ataki, a twoja firma poniesie konsekwencje. Alternatywnie, jeśli zrozumiesz przypadki użycia twojego oprogramowania i to, co twoi użytkownicy próbują osiągnąć, twoje oprogramowanie będzie lepsze, bezpieczniejsze i będziesz mógł ograniczyć liczbę e-maili „Przepraszamy…” wysyłanych do klientów.
Do dalszego czytania
Z tego miejsca możemy zagłębić się w protokoły, poszczególne biblioteki lub świetne książki na ten temat. Jeśli chcesz zrozumieć jak poszczególne RFC pasują do siebie, sprawdź książkę Aarona Pareckiego OAuth2.0 Simplified i jego towarzyszącą Mapę Specs OAuth 2.0. To jest mój go to cheatsheet na linki do kluczowych specyfikacji i który z nich obejmuje co. Wszystko to zainspirowało mój przewodnik Recommended Practices for API Access Management, który szczegółowo opisuje zasady dobrego projektowania i rozwoju klientów OAuth, serwerów autoryzacyjnych, bram API i aplikacji.