Czy pliki cookie powinny być używane w interfejsie API RESTful?

Szczególnie interesuje mnie sposób, w jaki użytkownicy wykonują autoryzowane / uwierzytelnione operacje w internetowym interfejsie API.

Czy uwierzytelniające pliki cookie są zgodne z filozofią REST i dlaczego?

web-applications web-services rest

— Brandon Linton
źródło

dokładny duplikat uwierzytelnienia restful

możliwy duplikat architektury oprogramowania do uwierzytelniania / kontroli dostępu do usługi REST

— FrustratedWithFormsDesigner

@JarrodRoberson Rozumiem, że odpowiedzi na innej stronie nie kwalifikują pytania jako duplikatu tutaj

— Tom Squires

@JarrodRoberson na podstawie najczęściej zadawanych pytań dotyczących każdej witryny, twierdzę, że pytanie należy do tej witryny, a nie do przepełnienia stosu. Interesuje mnie metodologia / filozofia projektowania i kompromisy dotyczące tego aspektu architektury RESTful. Przepełnienie stosu jest przeznaczone na pytania dotyczące implementacji, w których ta strona dotyczy bardziej metodologii projektowania i kompromisów.

— Brandon Linton

Zgadzam się z @BrandonLinton tutaj, pytanie jest zbyt ogólne dla Stackoverflow, dotyczy to architektury i metodologii projektowania. OP chce najlepszych praktyk i wzorców, sugestii i gotchas - a nie konkretnej odpowiedzi - dlatego też nie określono języka. Dlatego należy tutaj.

— dooburt

Odpowiedzi:

Idealna usługa ReSTful pozwala klientom (które mogą nie być w przeglądarce) wykonywać dowolne zadania w jednym żądaniu ; ponieważ pełny stan potrzebny do tego jest w posiadaniu klienta, a nie serwera. Ponieważ klient ma pełną kontrolę nad stanem, może sam tworzyć stan (jeśli jest to uzasadnione) i rozmawiać tylko z interfejsem API, aby „załatwić sprawę”.

Wymaganie plików cookie może to utrudnić. Dla klientów poza przeglądarkami zarządzanie plikami cookie jest dość dużą niedogodnością w porównaniu z parametrami zapytań, zwykłymi nagłówkami żądań lub treścią żądania. Z drugiej strony, w przeglądarce korzystanie z plików cookie może znacznie uprościć wiele rzeczy.

Interfejs API może więc najpierw sprawdzić w Authorizationnagłówku potrzebne dane uwierzytelniające, ponieważ prawdopodobnie jest to miejsce, w którym klienci spoza przeglądarki wolą je umieścić, ale aby uprościć i usprawnić klientów opartych na przeglądarce, może również sprawdzić plik cookie sesji do logowania po stronie serwera, ale tylko w przypadku Authorizationbraku zwykłego nagłówka.

Innym przykładem może być złożone żądanie, które zwykle wymaga dużej liczby parametrów. Nieinteraktywny klient nie miałby problemów z zablokowaniem wszystkich tych danych w jednym żądaniu, ale interfejs oparty na formularzu HTML może chcieć podzielić żądanie na kilka stron (coś w rodzaju zestawu stron „kreatora”), aby użytkownicy nie byli prezentowani z opcjami, które nie mają zastosowania na podstawie poprzednich wyborów. Wszystkie strony pośrednie mogą przechowywać wartości w plikach cookie po stronie klienta, dzięki czemu tylko ostatnia strona, na której użytkownik faktycznie przesyła żądanie, ma w ogóle jakikolwiek efekt uboczny po stronie serwera. Interfejs API może wyszukać potrzebne atrybuty w treści żądania i wrócić do przeglądania plików cookie, jeśli nie ma wymaganych parametrów.

Edytuj: w RE do komentarza @ Konrad poniżej:

Tokeny w porównaniu są trudniejsze do wdrożenia, zwłaszcza że nie można łatwo unieważnić tokena bez przechowywania go gdzieś.

er ... sprawdzasz poprawność plików cookie po stronie serwera, prawda? To, że kazałeś przeglądarce odrzucić plik cookie po 24 godzinach, nie oznacza, że tak będzie. Ten plik cookie może zostać zapisany przez wysoce technicznego użytkownika i ponownie użyty długo po jego „wygasnięciu”.

Jeśli nie chcesz przechowywać danych sesji po stronie serwera, powinieneś zapisać je w tokenie (plik cookie lub w inny sposób). Samodzielny token uwierzytelniania jest czasem nazywany makaronikiem. Sposób, w jaki jest przekazywany między klientem a serwerem (czy to przez plik cookie, jako dodatkowe nagłówki, czy w samej jednostce żądania) jest całkowicie niezależny od samego mechanizmu uwierzytelniania.

— SingleNegationElimination
źródło

+1, zdecydowanie podoba mi się praktyczność użycia nagłówka Autoryzacja, ale „cofanie się” do plików cookie w zależności od tego, co działa najlepiej dla klienta.

— Brandon Linton

Nie zgadzam się z „Dla klientów poza przeglądarkami zarządzanie plikami cookie to dość duża niedogodność ...”. Biblioteki klienckie HTTP obsługują głównie pliki cookie, na przykład HttpClientw .NET można bez problemu używać plików cookie i nie trzeba o tym myśleć. Tokeny w porównaniu są trudniejsze do wdrożenia, zwłaszcza że nie można łatwo unieważnić tokena bez przechowywania go gdzieś.

— Konrad

@Konrad tylko dlatego, że jest łatwy w niektórych klientach niebędących przeglądarkami, nie oznacza, że jest łatwy we wszystkich. W porządku, jeśli potrzebujesz obsługiwać konkretnego klienta, którego używasz, ale zinterpretowałem to pytanie o publiczne interfejsy API. w curllub wgetzarządzanie plikami cookie jest naprawdę niewygodne i naprawdę musisz o nich pomyśleć. Odpowiedziałem na inny punkt, edytując moją odpowiedź.

— SingleNegationElimination

Uwaga: samo zaakceptowanie plików cookie otwiera luki w CSRF. Zobacz także security.stackexchange.com/a/166798

— Michael Osl

Tak i nie - zależy od tego, jak z niego korzystasz.

Pliki cookie, jeśli są używane do utrzymania stanu klienta na kliencie, dla klienta, klienta i klienta, są spokojne.

Jeśli zapisujesz stan serwera w pliku cookie, to po prostu przenosisz obciążenie na klienta - co nie jest spokojne.

Jakie są więc przykłady?

Spokojny:

Dane uwierzytelniające lub „zalogowany” to coś w rodzaju
ostatnio oglądana strona lub miejsce w aplikacji itp.

Niepokojący:

Przechowywanie informacji o sesji

Spokój wynika z bezpaństwowości - serwera. Klienci mogą utrzymywać stan aplikacji i wysyłać ją do serwera, aby powiedzieć, gdzie są, aby serwer mógł zdecydować, dokąd się udać. Zasadniczo sesje / stany potrzebują danych historycznych i są zależne od wcześniejszych żądań, że tak powiem, aplikacje relaksujące idealnie nie są (nie jest opłacalne, aby mieć aplikację w 100% czystą, jeśli chcesz mieć ekran logowania :)

— Doktorat
źródło

Jeśli przechowujesz flagę „isLoggedIn” na kliencie, równie dobrze możesz nie używać uwierzytelniania.

— tdammers

To zdecydowanie ma sens - przechowywanie stanu aplikacji po stronie klienta nie byłoby spójne z REST, ale informacje o kliencie, których używa do reprezentowania siebie, wydają się w porządku.

— Brandon Linton

Chciałbym dodać, że umieszczenie informacji uwierzytelniających w plikach cookie pozostawia otwartą możliwość ataków typu „fałszowanie żądań w różnych witrynach”. Są lepsze sposoby, sugeruję kopiowanie Amazon: docs.aws.amazon.com/AmazonS3/latest/API/…

— Dobes Vandermeer

@tdammers, a co jeśli flaga „isLoggedIn” znajduje się w JWT? To powinno być bezpieczne, pod warunkiem, że JWT zostanie wydany i poprawnie zweryfikowany.

— Aaron J Spetner

@AaronJSpetner: Nie używaj JWT do sesji .

— tdammers

Można używać plików cookie. REST pozwala im.

REST wymaga, aby wszelkie informacje o sesji były przechowywane po stronie klienta, ale jeśli chodzi o uwierzytelnianie, niektóre informacje muszą pozostać po stronie serwera ze względów bezpieczeństwa.

Z jednego z moich postów na blogu wynika ogólna zgoda, że dane uwierzytelniające są uznawane za nieobjęte zakresem REST. Dlatego serwery mogą przechowywać niektóre dane sesji po swojej stronie.

— Jérôme Verstrynge
źródło