Dwuetapowa autoryzacja OAuth 2.0 vs SSL/TLS

Question

Mam dwa serwery korporacyjne, które muszą komunikować się w bezpieczny sposób i porównywane są przy użyciu protokołu SSL (z certyfikatami klient/serwer do sprawdzania obu stron) w porównaniu do uwierzytelniania dwunożnego przy użyciu protokołu OAuth 2.0 (opcjonalnie z tokenami MAC lub tokenami JWT).

Historycznie wydaje się, że OAuth został stworzony dla zupełnie innego celu (trójnogiego przypadku, w którym użytkownik zezwala usłudze na dostęp do niektórych danych) i chociaż dwunożny jest teraz zintegrowany ze specyfikacją OAuth 2.0, z tego, co widziałem, dwunożny OAuth 2.0 nie wydaje się oferować dodatkowej ochrony przez SSL.

Jedyną rzeczą, o której mogę myśleć jest to, że OAuth jest potencjalnie łatwiejszy do skonfigurowania niż SSL i łatwo popełnić błędy, np. Akceptując złe certyfikaty SSL, które mogą zagrozić bezpieczeństwu. Jednak nie jestem pewien, czy jest to wystarczający powód, aby przejść z OAuth.

Zauważ, że wspominam o nich jako o oddzielnych opcjach, ale myślę, że użycie OAuth prawdopodobnie pociągnęłoby za sobą użycie protokołu HTTPS/SSL, więc oba zostałyby użyte.

Czy istnieją rzeczywiste zalety korzystania z dwunożnego schematu OAuth 2.0 do komunikacji między serwerami (bez udziału użytkownika)?

Uwaga: Znalazłem nieco podobny post here, ale jest dość stary, ale nie sądzę, że dał satysfakcjonującą odpowiedź w tej sprawie.

Answer 1

będę odpowiedzi na ten komentarz:

Moje pytanie jest, że przy założeniu używam SSL z odpowiednimi CERT klient/serwer, aby zidentyfikować każdą maszynę, jaką wartość będzie za pomocą OAuth (2 nogami lub podobny) na dodatek, aby autoryzować serwery sobie nawzajem (zakładając, że nie ma żadnego użytkownika). Dzięki - Locksleyu

Podsumowanie: Nie zawracałbym sobie głowy robieniem obu.

Szczegóły: 2-legged OAUTH jest tak bezpieczny, jak tajemnica klienta. Podobnie wzajemne uwierzytelnianie SSL jest tak samo bezpieczne jak klucz prywatny. Zakładam, że będziesz przechowywać je w jakimś zaszyfrowanym magazynie na każdym serwerze. Ponieważ oba są przechowywane w tym samym miejscu, nie widzę dodatkowych zabezpieczeń, które wynikają z dodania OAUTH.

Teraz, jeśli rozważasz wybór między protokołem SSL a standardowym SSL z uwierzytelnianiem, być może OAUTH może tam odgrywać rolę. Poszedłbym z tą opcją, która wydaje się łatwiejsza. Więc jeśli masz system OAUTH w miejscu i możesz z łatwością dodać do niego autoryzację serwera, być może właśnie tak możesz.W przeciwnym razie, po prostu idź z wzajemnym uwierzytelnianiem SSL. Zwykle konfiguracja jest trudna, ale działa dobrze i szybko po skonfigurowaniu.

Answer 2

Przepraszam, jeśli już to wiesz, ale nie jest to jasne w Twoim poście.

OAuth i SSL \ TLS to dwie osobne warstwy modelu OSI. Protokół OAuth służy do uwierzytelniania i znajduje się u góry w warstwie 7, a protokół SSL \ TLS służy do zabezpieczenia transportu w warstwie 4. Łatwo jest pomylić protokół SSL z certyfikatami klienta, ponieważ oba korzystają z PKI.

Masz rację w swojej wiedzy na temat OAuth ... służy do autoryzacji osób, a nie organizacji \ serwerów. Dwuetapowa autoryzacja OAuth to termin, który obejmuje różne alternatywne przepływy OAuth, z których wszystkie nie są zgodne ze standardem.

Moim zdaniem, chcesz używać certyfikatów klienta do zabezpieczenia komunikacji serwer-serwer ... wszystko, czego naprawdę potrzebujesz, to pojedynczy certyfikat x509, który może być używany zarówno jako SSL (bezpieczeństwo transportu), jak i certyfikat klienta (autoryzacja); chociaż używanie 2 certyfikatów jest normą.