RESTful Authentication

Co oznacza RESTful Authentication i jak to działa? Nie mogę znaleźć dobrego przeglądu w Google. Rozumiem tylko, że przekazujesz klucz sesji (remeberal) w adresie URL, ale może to być strasznie złe.

Author: Arslan Ali, 2008-11-26
Source

14 answers

Jak obsługiwać uwierzytelnianie w RESTful architektura klient-serwer jest kwestią dyskusyjną.

Powszechnie można to osiągnąć, w SOA poprzez świat HTTP poprzez:

  • HTTP basic auth over HTTPS;
  • Pliki cookie i zarządzanie sesjami;
  • Token w nagłówkach HTTP (np. OAuth 2.0 + JWT);
  • uwierzytelnianie zapytań z dodatkowymi parametrami podpisu.

Będziesz musiał dostosować, a nawet lepiej wymieszać te techniki, aby pasowały do twojego Architektura oprogramowania w najlepszym wydaniu.

Każdy schemat uwierzytelniania ma swoje wady i zalety, w zależności od celu polityki bezpieczeństwa i architektury oprogramowania.

HTTP basic auth over HTTPS

To pierwsze rozwiązanie, oparte na standardowym protokole HTTPS, jest używane przez większość serwisów internetowych.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Jest łatwy w implementacji, dostępny domyślnie we wszystkich przeglądarkach, ale ma pewne znane wady, takie jak okropne okno uwierzytelniania wyświetlane w przeglądarce, które będą się utrzymywać (nie ma tutaj funkcji przypominającej wylogowanie), niektóre dodatkowe zużycie procesora po stronie serwera oraz fakt, że nazwa użytkownika i hasło są przesyłane (przez HTTPS) do serwera (powinno być bezpieczniejsze, aby hasło pozostało tylko po stronie klienta, podczas wprowadzania klawiatury i być przechowywane jako bezpieczny hash na serwerze).

Możemy używać Digest Authentication, ale wymaga również HTTPS, ponieważ jest podatny na ataki MiM lub Replay , i jest specyficzna dla HTTP.

Session via Cookies

Szczerze mówiąc, sesja zarządzana na serwerze nie jest tak naprawdę Bezpaństwowa.

Jedną z możliwości może być zachowanie wszystkich danych w treści Plików cookie. Z założenia plik cookie jest obsługiwany po stronie serwera(klient nawet nie próbuje zinterpretować tych danych cookie: po prostu przekazuje je z powrotem do serwera przy każdym kolejnym żądaniu). Ale te dane cookie są danymi stanu aplikacji, więc klient powinien zarządzać to, nie serwer, w czystym, Bezpaństwowym świecie.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Sama technika cookie jest powiązana z HTTP, więc nie jest naprawdę spokojna, co powinno być niezależne od protokołu, IMHO. Jest podatny na ataki MiM lub Replay.

Przyznawany za pomocą tokena (OAuth2)

Alternatywą jest umieszczenie tokena w nagłówkach HTTP, aby żądanie zostało uwierzytelnione. To właśnie robi OAuth 2.0 na przykład. Zobacz RFC 6749:

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

Krótko mówiąc, jest to bardzo podobne do pliku cookie i cierpi na te same problemy: nie jest bezpaństwowy, opiera się na szczegółach transmisji HTTP i podlega wielu słabościom Bezpieczeństwa - W tym MiM I Replay - więc może być używany tylko przez HTTPS. Zazwyczaj jako token używany jest JWT.

Uwierzytelnianie Zapytań

Uwierzytelnianie zapytań polega na podpisywaniu każdego żądania RESTful za pomocą dodatkowych parametrów na URI. Zobacz też ten artykuł referencyjny .

Został zdefiniowany jako taki w tym artykule:

Wszystkie zapytania REST muszą być uwierzytelnione przez podpisanie parametrów zapytania sortowane małymi literami, W porządku alfabetycznym przy użyciu prywatnego poświadczenia jako token podpisywania. Podpisywanie powinno nastąpić przed zakodowaniem adresu URL ciąg zapytania.

Technika ta jest prawdopodobnie bardziej kompatybilna z architekturą Bezpaństwową, a także może być zaimplementowana z lekkim zarządzaniem sesjami (za pomocą sesje w pamięci zamiast DB persistence).

Na przykład, oto ogólna próbka URI z linku powyżej: 

GET /object?apiKey=Qwerty2010

Powinny być przekazywane jako takie: 

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

Podpisywany łańcuch to /object?apikey=Qwerty2010&timestamp=1261496500, a podpis to hash SHA256 tego łańcucha przy użyciu prywatnego komponentu klucza API.

Buforowanie danych po stronie serwera może być zawsze dostępne. Na przykład w naszym frameworku buforujemy odpowiedzi na poziomie SQL, a nie na poziomie URI. Więc dodanie tego dodatkowego parametr nie łamie mechanizmu cache.

Zobacz ten artykuł aby dowiedzieć się więcej o uwierzytelnianiu RESTful w naszym systemie klient-serwer ORM/SOA/MVC, opartym na JSON i REST. Ponieważ pozwalamy na komunikację nie tylko poprzez HTTP/1.1, ale także nazwane pipes lub wiadomości GDI (lokalnie), staraliśmy się zaimplementować prawdziwie RESTful uwierzytelniania wzorzec, a nie polegać na specyfice HTTP (jak nagłówek lub pliki cookie).

późniejsza Uwaga : dodanie podpisu w URI można zobaczyć jak zła praktyka (bo np. pojawi się w logach serwera http), więc musi być złagodzone, np. przez odpowiedni TTL, aby uniknąć powtórek. Ale jeśli Twoje logi http zostaną naruszone, na pewno będziesz miał większe problemy z bezpieczeństwem.

W praktyce, nadchodzące uwierzytelnianie tokenów MAC dla OAuth 2.0 może być ogromną poprawą w stosunku do obecnego schematu "Granted by Token". Ale to nadal jest praca w toku i jest związany z HTTP transmisja.

Wniosek

Warto wywnioskować, że REST jest nie tylko oparty na HTTP, nawet jeśli w praktyce jest również w większości zaimplementowany przez HTTP. REST może korzystać z innych warstw komunikacyjnych. Tak więc uwierzytelnianie RESTful nie jest tylko synonimem uwierzytelniania HTTP, niezależnie od odpowiedzi Google. Nie powinna nawet w ogóle korzystać z mechanizmu HTTP, ale powinna być wyodrębniona z warstwy komunikacyjnej. A jeśli korzystasz z komunikacji HTTP, dzięki Let ' s Encrypt initiative nie ma powodu, aby nie używać odpowiedniego HTTPS, który jest wymagany oprócz każdego schematu uwierzytelniania.

 607
Author: Arnaud Bouchez,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-10-24 10:01:38

Wątpię, czy ludzie entuzjastycznie krzyczący "Uwierzytelnianie HTTP" kiedykolwiek próbowali zrobić aplikację opartą na przeglądarce (zamiast usługi internetowej maszyna-maszyna) z resztą (bez obrazy-po prostu nie sądzę, że kiedykolwiek mieli do czynienia z komplikacjami).

Problemy, które znalazłem przy użyciu uwierzytelniania HTTP w usługach RESTful, które produkują strony HTML do przeglądania w przeglądarce to:

  • użytkownik zazwyczaj dostaje brzydkie okno logowania wykonane przez przeglądarkę, co jest bardzo nieprzyjazne dla użytkownika. nie można dodać wyszukiwania haseł, pól pomocy itp.
  • wylogowanie się lub logowanie pod inną nazwą jest problemem-przeglądarki będą wysyłać informacje uwierzytelniające do witryny, dopóki nie zamkniesz okna
  • timeouts are difficult

Bardzo wnikliwym artykułem, który porusza te kwestie punkt po punkcie jest tutaj, ale to powoduje wiele specyficznych dla przeglądarki hackery javascript, obejścia dla obejść, itp. Jako takie, nie jest również kompatybilny z forward, więc będzie wymagał stałej konserwacji, ponieważ nowe przeglądarki są wydawane. Nie uważam, że czysty i przejrzysty projekt, a do tego czuję, że jest to dużo dodatkowej pracy i bólu głowy, tylko po to, abym mógł entuzjastycznie pokazać moją odznakę odpoczynku moim znajomym.

Uważam, że ciasteczka są rozwiązaniem. Ale czekaj, ciasteczka są złe, prawda? Nie, Nie Są, sposób, w jaki Pliki cookie są często używane, jest zły. Sam plik cookie jest tylko fragmentem informacji po stronie klienta, podobnie jak informacje uwierzytelniające HTTP że przeglądarka będzie śledzić podczas przeglądania. Ta informacja po stronie klienta jest wysyłana do serwera na każde żądanie, podobnie jak informacje uwierzytelniające HTTP. Koncepcyjnie jedyną różnicą jest to, że zawartość tego fragmentu stanu po stronie klienta może być określona przez Serwer jako część jego odpowiedzi.

Czyniąc sesje źródłem odpoczynku z następującymi zasadami:

  • a sesja mapuje klucz do user id (i ewentualnie last-action-timestamp dla timeouts)
  • Jeśli istnieje sesja , oznacza to, że klucz jest ważny.
  • Logowanie oznacza wysyłanie do / sesji, nowy klucz jest ustawiany jako plik cookie
  • wylogowanie oznacza usuwanie / sesje / {klucz} (z przeciążonym postem, pamiętaj, że jesteśmy przeglądarką, a HTML 5 to jeszcze długa droga)
  • uwierzytelnianie odbywa się poprzez wysłanie klucza jako pliku cookie na każde żądanie i sprawdzenie, czy sesja istnieje i jest valid

Jedyną różnicą w stosunku do uwierzytelniania HTTP jest to, że klucz uwierzytelniania jest generowany przez serwer i wysyłany do klienta, który wciąż odsyła go z powrotem, zamiast klienta obliczającego go z wprowadzonych poświadczeń.

Converter42 dodaje, że podczas korzystania z https (co powinniśmy), ważne jest, aby plik cookie miał ustawioną bezpieczną flagę, aby informacje o uwierzytelnianiu nigdy nie były wysyłane przez niezabezpieczone połączenie. Słuszna Uwaga, sam tego nie widziałem.

I czuję, że jest to wystarczające rozwiązanie, które działa dobrze, ale muszę przyznać, że nie jestem wystarczająco ekspertem ds. bezpieczeństwa, aby zidentyfikować potencjalne dziury w tym schemacie - wiem tylko, że setki Nie RESTful aplikacji internetowych używają zasadniczo tego samego protokołu logowania ($_SESSION w PHP, HttpSession w Java EE, itp.). Zawartość nagłówka cookie są po prostu używane do adresowania zasobów po stronie serwera, podobnie jak accept-language może być używany do dostępu do zasobów tłumaczeniowych, etcetera. Czuję, że jest to to samo, ale może inni nie? Co o tym myślicie?

 421
Author: skrebbel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-10-05 11:46:04

Dość już zostało powiedziane na ten temat przez dobrych ludzi tutaj. Ale tu są moje 2 centy.

Istnieją 2 tryby interakcji:

  1. human-to-machine (HTM)
  2. machine-to-machine (MTM)

Maszyna jest wspólnym mianownikiem, wyrażonym jako Pozostałe API, a aktorami / klientami są albo ludzie, albo maszyny.

Teraz, w architekturze prawdziwie relaksującej, pojęcie bezpaństwowości zakłada, że wszystkie istotne Stany aplikacji (czyli klient Stany boczne) muszą być dostarczane z każdym żądaniem. Przez odpowiednie rozumie się, że wszystko, co jest wymagane przez REST API do przetworzenia żądania i dostarczenia odpowiedniej odpowiedzi.

Gdy rozważamy to w kontekście aplikacji człowiek-maszyna, "opartych na przeglądarce", jak wskazuje Skrebbel powyżej, oznacza to, że aplikacja (internetowa) uruchomiona w przeglądarce będzie musiała wysyłać swój stan i istotne informacje przy każdym złożonym zapytaniu do interfejsów API REST zaplecza.

Rozważ to: masz platformę danych/informacji narażony zasób API REST. Być może masz samoobsługową platformę BI, która obsługuje wszystkie kostki danych. Ale chcesz, aby Twoi (ludzcy) klienci mieli dostęp do tego za pośrednictwem (1) aplikacji internetowej, (2) aplikacji mobilnej i (3) aplikacji innej firmy. W końcu nawet łańcuch MTMs prowadzi do HTM-right. Tak więc ludzie pozostają na szczycie łańcucha informacji.

W pierwszych 2 przypadkach, masz przypadek interakcji człowiek-maszyna, informacje faktycznie konsumowane przez ludzkiego użytkownika. W ostatnim przypadku masz program komputerowy zużywający Pozostałe interfejsy API.

Pojęcie uwierzytelniania ma zastosowanie wszędzie. Jak zaprojektujesz to tak, aby Twoje interfejsy API REST były dostępne w jednolity, bezpieczny sposób? Ja to widzę, są 2 sposoby:

Sposób-1:

  1. nie ma logowania, na początek. Każde żądanie wykonuje login
  2. Klient wysyła swoje parametry identyfikujące + zapytanie szczegółowe parametry dla każdego żądania
  3. REST API zabiera je, odwraca, pingi do sklepu użytkownika (cokolwiek to jest) i potwierdza auth
  4. Jeśli auth jest ustanowiony, obsługuje żądanie; w przeciwnym razie zaprzecza z odpowiednim kodem statusu HTTP
  5. Powtórz powyższe dla każdego żądania we wszystkich pozostałych API w Twoim katalog

Sposób-2:

  1. Klient zaczyna się żądaniem auth
  2. login REST API będzie obsługiwał wszystkie takie requests
  3. pobiera parametry auth (klucz API, uid / pwd lub cokolwiek innego wybierz) i weryfikuje auth względem sklepu użytkownika (LDAP, AD lub MySQL DB itp.)
  4. jeśli zostanie zweryfikowany, tworzy Token auth i przekazuje go z powrotem do klient / rozmówca
  5. wywołujący następnie wysyła ten auth token + request specific params z każde kolejne żądanie do innych interfejsów API REST business, do czasu wylogowania lub wygaśnięcia umowy najmu

Oczywiście, W Way-2, Pozostałe API będą potrzebowały sposobu rozpoznania i zaufaj tokenowi jako ważny. Interfejs API logowania przeprowadził weryfikację auth i dlatego ten "klucz parkingowego" musi być zaufany przez inne interfejsy API REST w katalogu.

Oznacza to oczywiście, że klucz/token auth będzie musiał być przechowywany i udostępniany między pozostałymi API. To współdzielone, zaufane repozytorium tokenów może być lokalne/federacyjne, co pozwala API REST od innych organizacji ufać sobie nawzajem.

Ale dygresję.

Chodzi o to, że "stan" (o kliencie uwierzytelniony status) musi zostać utrzymany i udostępniony, aby wszystkie API REST mogły stworzyć krąg zaufania. Jeśli tego nie zrobimy, czyli Way-1, musimy zaakceptować, że akt uwierzytelnienia musi zostać wykonany dla wszystkich / wszystkich zgłoszeń.

Wykonywanie uwierzytelniania jest procesem wymagającym dużej ilości zasobów. Wyobraź sobie wykonywanie zapytań SQL dla każdego przychodzącego żądania w sklepie użytkownika, aby sprawdzić zgodność uid / pwd. Lub, aby zaszyfrować i wykonać dopasowania hash (styl AWS). Oraz architektonicznie, każde API REST będzie musiało to wykonać, podejrzewam, za pomocą wspólnej usługi logowania back-end. Bo jeśli nie, to wszędzie zaśmiecasz kod auth. Wielki bałagan.

Więc więcej warstw, więcej latencji.

Teraz weź Way - 1 i zastosuj do HTM. Czy twój (ludzki) użytkownik naprawdę obchodzi, czy musisz wysyłać uid / pwd / hash lub cokolwiek innego przy każdym żądaniu? Nie, pod warunkiem, że nie przeszkadzasz jej rzucając stronę auth / login co sekundę. Powodzenia z klientami. Tak więc, co zrobisz, to przechowasz dane logowania gdzieś po stronie klienta, w przeglądarce, na samym początku, i wysłać je z każdym złożonym żądaniem. Dla użytkownika (człowieka), jest już zalogowana, a" sesja " jest dostępna. Ale w rzeczywistości jest uwierzytelniana na każde żądanie.

To samo z Way-2. Twój (ludzki) użytkownik nigdy nie zauważy. Więc nic się nie stało.

Co jeśli zastosujemy Way-1 do MTM? W tym przypadku, ponieważ jest to maszyna, możemy zanudzić tego faceta w piekle prosząc go o przesłanie informacji uwierzytelniających przy każdym żądaniu. Nikogo to nie obchodzi! Wykonanie Way-2 na MTM nie wywoła żadnej specjalnej reakcji; to cholerna maszyna. Nie obchodzi mnie to!

Tak naprawdę, pytanie brzmi, co odpowiada twoim potrzebom. Bezpaństwowość ma swoją cenę do zapłacenia. Zapłać cenę i idź dalej. Jeśli chcesz być purystą, to zapłać za to cenę i idź dalej.

W końcu filozofie nie mają znaczenia. To, co naprawdę się liczy, to odkrywanie informacji, prezentacja i doświadczenie konsumpcyjne. Jeśli ludzie kochają Twoje API, wykonałeś swoją pracę.

 147
Author: Kingz,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-10-05 11:40:20

Oto prawdziwie i całkowicie RESTful rozwiązanie uwierzytelniania:

  1. Utwórz parę kluczy publicznych/prywatnych na serwerze uwierzytelniania.
  2. rozpowszechniaj klucz publiczny na wszystkie serwery.

  3. Gdy klient uwierzytelnia:

    3.1. wystaw token, który zawiera:

    • czas ważności
    • Nazwa użytkownika (opcjonalnie)
    • users IP (opcjonalnie)
    • hash hasła (opcjonalnie)

    3.2. Zaszyfruj token za pomocą klucz prywatny.

    3.3. Wyślij zaszyfrowany token z powrotem do użytkownika.

  4. Gdy użytkownik uzyskuje dostęp do dowolnego API, musi również przekazać swój token auth.

  5. serwery mogą sprawdzić, czy token jest ważny, odszyfrowując go za pomocą klucza publicznego serwera auth.

To jest uwierzytelnianie bezstanowe/RESTful.

Zauważ, że jeśli zostanie dołączony hash hasła, Użytkownik wyśle również niezaszyfrowane hasło wraz z tokenem uwierzytelniania. Serwer może sprawdź, czy hasło pasowało do hasła używanego do utworzenia tokenu uwierzytelniania, porównując skróty. Konieczne byłoby bezpieczne połączenie przy użyciu czegoś takiego jak HTTPS. Javascript po stronie klienta może obsługiwać uzyskanie hasła użytkownika i przechowywanie go po stronie klienta, w pamięci lub w pliku cookie, ewentualnie zaszyfrowane za pomocą klucza serwera public.

 53
Author: jcoffland,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-09-02 00:07:04

Szczerze mówiąc, Widziałem tu świetne odpowiedzi, ale coś, co mnie trochę martwi, to kiedy ktoś zabierze całą koncepcję bezpaństwowości do skrajności, gdzie staje się dogmatyczna. Przypomina mi to tych starych fanów Smalltalka, którzy chcieli tylko objąć czyste OO i jeśli coś nie jest przedmiotem, to robisz to źle. Daj spokój.

Spokojne podejście ma ułatwić Ci życie i zmniejszyć koszty i koszty sesji, staraj się go przestrzegać, ponieważ jest to mądre rzecz do zrobienia, ale w chwili, gdy podążasz za dyscypliną (jakąkolwiek dyscypliną/wytycznymi) do ekstremum, w którym nie zapewnia już korzyści, do których była przeznaczona, robisz to źle. Niektóre z najlepszych języków mają zarówno programowanie funkcyjne, jak i orientację obiektową.

Jeśli najprostszym sposobem rozwiązania problemu jest zapisanie klucza uwierzytelniania w pliku cookie i wysłanie go do nagłówka HTTP, zrób to, po prostu nie nadużywaj go. Pamiętaj, że sesje są złe, gdy stają się ciężkie i duże, jeśli cała sesja składa się z krótkiego ciągu zawierającego klucz, to w czym problem?

Jestem otwarty na poprawki w komentarzach, ale po prostu nie widzę sensu (jak na razie) w uprzykrzaniu naszego życia, aby po prostu uniknąć trzymania dużego słownika hashów na naszym serwerze.

 39
Author: arg20,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-08-13 20:09:03

Po pierwsze i najważniejsze, RESTful web service jest STATELESS (lub innymi słowy, SESSIONLESS). W związku z tym usługa RESTful nie ma i nie powinna mieć pojęcia sesji lub plików cookie. Metoda uwierzytelniania lub autoryzacji w usłudze RESTful polega na użyciu nagłówka autoryzacji HTTP zdefiniowanego w specyfikacji HTTP RFC 2616. Każde żądanie powinno zawierać nagłówek autoryzacji HTTP, a żądanie powinno być wysyłane przez HTTPs (SSL) połączenie. Jest to prawidłowy sposób uwierzytelniania i weryfikacji autoryzacji żądań w usługach sieciowych http RESTful. Zaimplementowałem usługę RESTful web dla aplikacji Cisco PRIME Performance Manager w Cisco Systems. W ramach tej usługi internetowej zaimplementowałem również uwierzytelnianie/autoryzację.

 33
Author: rubens,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-08-09 08:57:28

Z pewnością nie chodzi tu o "klucze sesji", ponieważ jest ono zwykle używane w odniesieniu do uwierzytelniania bezsesyjnego, które odbywa się w ramach wszystkich ograniczeń REST. Każde żądanie jest samoopisujące się, zawiera wystarczająco dużo informacji, aby samodzielnie autoryzować żądanie bez żadnego stanu aplikacji po stronie serwera.

Najprostszym sposobem na to jest rozpoczęcie od wbudowanych mechanizmów uwierzytelniania HTTP w RFC 2617 .

 22
Author: Justin Sheehy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-26 03:06:21

"bardzo wnikliwy" artykuł wspomniany przez @skrebel ( http://www.berenddeboer.net/rest/authentication.html ) omawia zawiłą, ale naprawdę zepsutą metodę uwierzytelniania.

Możesz spróbować odwiedzić stronę (która ma być widoczna tylko dla uwierzytelnionego użytkownika) http://www.berenddeboer.net/rest/site/authenticated.html bez żadnych danych logowania.

(Sorry nie mogę skomentować odpowiedzi.)

Powiedziałbym, że odpoczynek i uwierzytelnianie po prostu nie mieszać. Reszta oznacza bezpaństwowiec, ale "uwierzytelniony" jest stanem. Nie możesz mieć ich obu na tej samej warstwie. Jeśli jesteś spokojnym orędownikiem i marszczysz brwi na Stanach, musisz przejść z HTTPS (tzn. pozostawić problem bezpieczeństwa innej warstwie).

 15
Author: Ji Han,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-15 19:35:58

[[0]} aktualizacja na 16-Feb-2019

Podejście wymienione poniżej jest zasadniczo" poświadczenie hasła właściciela zasobów " typu dotacji OAuth2.0. Jest to łatwy sposób na rozpoczęcie pracy. Jednak dzięki takiemu podejściu każda aplikacja w organizacji będzie miała własne mechanizmy uwierzytelniania i autoryzacji. Zalecanym podejściem jest typ dotacji "kod autoryzacji". Dodatkowo w mojej wcześniejszej Odpowiedzi poniżej polecam przeglądarkę localStorage do przechowywania auth żetony. Jednak doszedłem do przekonania, że cookie jest odpowiednią opcją do tego celu. Mam szczegółowe moje powody, podejście do implementacji kodu autoryzacji, względy bezpieczeństwa itp. w odpowiedź StackOverflow .

Myślę, że do uwierzytelniania usługi REST można użyć następującego podejścia:

  1. Utwórz login RESTful API, aby zaakceptować nazwę użytkownika i hasło do uwierzytelniania. Użyj metody HTTP POST, aby zapobiec buforowaniu I SSL dla bezpieczeństwa podczas tranzyt Po pomyślnym uwierzytelnieniu API zwraca dwa JWTs - jeden token dostępu (krótsza Ważność, powiedzmy 30 minut) i jeden token odświeżania (dłuższa Ważność, powiedzmy 24 godziny) {]} JWTs (ang. access token) - usługa, która umożliwia dostęp do JWTs (ang. access token), która umożliwia dostęp do JWTs (ang. access token).]}
  2. API sprawdza ważność tokena, weryfikując podpis i datę wygaśnięcia. Jeśli token jest ważny, sprawdź, czy użytkownik (to interpretuje twierdzenie "sub" w JWT jako username) ma dostęp do API za pomocą Cache lookup. Jeśli użytkownik jest uprawniony do dostępu do API, Uruchom logikę biznesową
    3. Jeśli token wygasł, API zwraca kod odpowiedzi HTTP 400
  3. klient, po otrzymaniu 400/401, wywołuje inne API REST z tokenem odświeżania w nagłówku "Authorization: Bearer #refresh token", aby uzyskać nowy token dostępu.
  4. po odebraniu połączenia z tokenem odświeżania sprawdź, czy token odświeżania jest prawidłowy sprawdzając podpis i datę ważności. Jeśli token odświeżania jest poprawny, odśwież pamięć podręczną prawa dostępu użytkownika z DB i zwróć nowy token dostępu i odśwież token. Jeśli token odświeżania jest nieprawidłowy, zwróć kod odpowiedzi HTTP 400
  5. jeśli zostanie zwrócony nowy token dostępu i token odświeżania, przejdź do kroku 2. Jeśli zwracany jest kod odpowiedzi HTTP 400, klient zakłada, że token odświeżania wygasł i pyta użytkownika o nazwę użytkownika i hasło
  6. dla wylogowania, Wyczyść local storage

Dzięki temu podejściu wykonujemy kosztowną operację ładowania pamięci podręcznej z konkretnymi danymi dostępu użytkownika co 30 minut. Jeśli więc dostęp zostanie cofnięty lub zostanie przyznany Nowy dostęp, refleksja trwa 30 minut lub wylogowanie po zalogowaniu.

 14
Author: Saptarshi Basu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-02-16 11:24:30

Myślę, że uwierzytelnianie restful polega na przekazaniu tokena uwierzytelniania jako parametru w żądaniu. Przykładami są użycie apikeys przez api. Nie wierzę, że użycie plików cookie lub HTTP AUTH kwalifikuje.

 12
Author: Bjorn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-19 06:45:34

W ten sposób można to zrobić: używając OAuth 2.0 do logowania.

Możesz używać innych metod uwierzytelniania niż Google, o ile obsługuje OAuth.

 8
Author: moshe beeri,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-12-09 00:12:57

Użycie klucza publicznego, w którym rejestracja klucza wymaga odpowiedniego wiązania, zapewnia, że klucz publiczny jest związany z osobą, do której jest przypisany, w sposób zapewniający brak odrzucenia

Zobacz http://en.wikipedia.org/wiki/Public_key_infrastructure . Jeśli zastosujesz się do odpowiednich standardów PKI, osoba lub agent, który niewłaściwie używa skradzionego klucza, może zostać zidentyfikowana i zablokowana. Jeśli agent jest zobowiązany do korzystania z certyfikatu, Wiązanie staje się dość mocno. Sprytny i szybki złodziej może uciec, ale zostawiają więcej okruchów.

 3
Author: DonB.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-02 04:08:40

Aby odpowiedzieć na to pytanie z mojego zrozumienia...

System Uwierzytelniania, który używa REST, dzięki czemu nie trzeba faktycznie śledzić lub zarządzać użytkownikami w systemie. Odbywa się to za pomocą metod HTTP POST, GET, PUT, DELETE. Bierzemy te 4 metody i myślimy o nich w kategoriach interakcji z bazą danych jako CREATE, READ, UPDATE, DELETE (ale w Internecie używamy POST I GET, ponieważ to jest to, co tags anchor obsługuje obecnie). Więc traktując POST i uzyskać jako nasz CREATE/READ/UPDATE / DELETE (CRUD) następnie możemy zaprojektować trasy w naszej aplikacji internetowej, które będą w stanie wydedukować, jakie działanie CRUD osiągamy.

Na przykład, w aplikacji Ruby on Rails możemy zbudować naszą aplikację internetową tak, że jeśli użytkownik zalogowany odwiedzi http://store.com/account/logout Następnie GET tej strony może być wyświetlany jako użytkownik próbujący wylogować. W naszym sterowniku rails zbudujemy akcję, która wyloguje użytkownika i odsyła go z powrotem do domu strona.

GET na stronie logowania daje formularz. POST na stronie logowania będzie postrzegany jako próba logowania i wziąć dane postu i użyć go do zalogowania.

Dla mnie jest to praktyka używania metod HTTP zmapowanych do ich znaczenia bazy danych, a następnie budowania systemu uwierzytelniania, mając to na uwadze, że nie musisz przekazywać żadnych identyfikatorów sesji ani śledzić sesji.

Wciąż się uczę-jeśli znajdziesz coś, co powiedziałem, że jest złe, popraw mnie, a jeśli nauczysz się więcej tutaj. Dzięki.

 2
Author: ,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-19 06:14:49

Wskazówki ważne przy zabezpieczaniu dowolnej aplikacji internetowej

Jeśli chcesz zabezpieczyć swoją aplikację, następnie zdecydowanie powinieneś zacząć od użycia HTTPS zamiast HTTP, zapewnia to tworzenie bezpiecznego kanału między tobą i użytkownikami, który zapobiegnie wąchaniu danych wysyłanych do użytkowników i pomoże zachować poufność wymienianych danych.

Możesz użyć Jwts (JSON Web Tokens), aby zabezpieczyć RESTful API , ma to wiele zalet w porównaniu z sesje po stronie serwera, korzyści są głównie:

1-bardziej skalowalne, ponieważ serwery API nie będą musiały utrzymywać sesji dla każdego użytkownika (co może być dużym obciążeniem, gdy masz wiele sesji)

2 - JWT są samodzielne i mają roszczenia, które definiują rolę użytkownika na przykład i do czego może uzyskać dostęp i wydane w dniu I dacie wygaśnięcia (po której JWT nie będzie ważny)

3-łatwiejsze w obsłudze przez load-balancers & jeśli masz wiele serwerów API, ponieważ nie będziesz musiał Udostępnij dane sesji ani skonfiguruj serwer, aby przekierował sesję na ten sam serwer, za każdym razem, gdy żądanie z JWT trafi na dowolny serwer, może być uwierzytelnione i autoryzowane

4-mniejszy nacisk na DB, a także nie będziesz musiał stale przechowywać i pobierać id sesji i dane dla każdego żądania

5-JWTs nie może być manipulowane, jeśli używasz silnego klucza do podpisania JWT, więc możesz zaufać roszczeniom w JWT, które są wysyłane z żądaniem bez konieczności sprawdzania sesji użytkownika i czy on jest upoważniony, czy nie, możesz po prostu sprawdzić JWT i wtedy jesteś ustawiony, aby wiedzieć, kto i co ten użytkownik może zrobić.

Wiele bibliotek zapewnia łatwe sposoby tworzenia i walidacji JWTs w większości języków programowania, na przykład: w node.js jednym z najbardziej popularnych jest jsonwebtoken

Ponieważ interfejsy API REST zazwyczaj mają na celu utrzymanie serwera bez stanu, więc JWT są bardziej zgodne z tą koncepcją , ponieważ każde żądanie jest wysyłane z tokenem autoryzacji, który jest samowystarczalny (JWT) bez konieczności śledzenia sesji użytkownika w porównaniu z sesjami, które sprawiają, że serwer jest Stanowy, aby zapamiętał użytkownika i jego rolę, jednak sesje są również szeroko stosowane i mają swoje zalety, które możesz wyszukać, jeśli chcesz.

Należy pamiętać, że musisz bezpiecznie dostarczyć JWT do klienta za pomocą HTTPS i zapisać go w bezpiecznym miejscu (na przykład w pamięci lokalnej).

Możesz dowiedzieć się więcej o JWTs Z tego link

 2
Author: Ahmed Elkoussy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-10-29 00:50:47