Wzór logowania REST API

Tworzę REST api, ściśle podążając za sugestiami apigee, używając rzeczowników nie czasowników, wersji api zapisanej w url, dwóch ścieżek api na kolekcję, GET POST PUT DELETE usage itp.

Pracuję nad systemem logowania, ale nie jestem pewien właściwego sposobu logowania użytkowników. W tym momencie nie pracuję nad bezpieczeństwem, tylko nad schematem logowania lub przepływem. (Później dodamy 2 Krok oAuth, z HMAC, itp)

Możliwe Opcje

  • POST do czegoś takiego https://api...com/v1/login.json
  • A PUT to something like https://api...com/v1/users.json
    • Coś, o czym nie pomyślałem...

Jaki jest właściwy styl odpoczynku dla zalogowanych użytkowników?

Author: Scott Roepnack, 2012-12-17
Source

3 answers

Pryncypialny projekt nowoczesnej architektury internetowej autorstwa Roya T. Fieldinga i Richarda N. Taylora, tj. Sekwencja prac z całej terminologii REST, zawiera definicję interakcji Klient-Serwer:

Wszystkie interakcje w spoczynku są bezpaństwowiec. Czyli każdy wniosek zawiera wszystkie informacje niezbędne do zrozumienia złącza wniosek, niezależnie od wszelkich wniosków, które mogły go poprzedzać.

To ograniczenie spełnia cztery funkcje, pierwsza i trzecia jest ważna w tym konkretnym przypadku:

  • 1st : It usuwa wszelkie potrzeby dla złączy, aby zachować stan aplikacji pomiędzy żądaniami , zmniejszając w ten sposób zużycie zasobów fizycznych i poprawa skalowalności;
  • 3rd : pozwala pośrednikowi przejrzeć i zrozumieć żądanie w izolacji , które mogą być konieczne, gdy usługi są dynamicznie rearranged;

A teraz wróćmy do twojej sprawy bezpieczeństwa. Każde żądanie powinno zawierać wszystkie wymagane informacje, a autoryzacja/uwierzytelnianie nie jest wyjątkiem. Jak to osiągnąć? Dosłownie przesyłaj wszystkie wymagane informacje za pomocą kabli przy każdym żądaniu.

Jednym z przykładów jak to zrobić jest hash - based message authentication code lub HMAC. W praktyce oznacza to dodanie kodu hashowego bieżącej wiadomości do każdego żądania. Hash kod obliczany przez kryptograficzną funkcję skrótu w połączeniu z tajnym kluczem kryptograficznym. kryptograficzna funkcja hashowa jest albo predefiniowana, albo częścią koncepcji REST code-on-demand (na przykład JavaScript). Tajny klucz kryptograficzny powinien być dostarczany przez serwer Klientowi jako zasób, a klient używa go do obliczania kodu skrótu dla każdego żądania.

Jest wiele przykładówHMAC implementacji, ale chciałbym, abyś zapłacił uwaga na następujące trzy:

Jak to działa w praktyce]}

Jeśli klient zna tajny klucz, jest gotowy do pracy z zasobami. W przeciwnym razie zostanie tymczasowo przekierowany (kod statusu 307 tymczasowe przekierowanie), aby autoryzować i uzyskać tajny klucz, a następnie przekierowany z powrotem do oryginalnego zasobu. W tym przypadku nie ma nie trzeba wiedzieć wcześniej (tj. gdzieś w twardym kodzie), jaki jest adres URL do autoryzacji klienta , i możliwe jest dostosowanie tego schematu z czasem.

Mam nadzieję, że pomoże Ci to znaleźć odpowiednie rozwiązanie!

 119
Author: Akim,
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
2017-05-23 12:02:48

TL; DR Logowanie dla każdego żądania nie jest komponentem wymaganym do implementacji zabezpieczeń API, uwierzytelnianie jest.

Trudno jest odpowiedzieć na twoje pytanie dotyczące logowania bez mówienia o bezpieczeństwie w ogóle. W przypadku niektórych systemów uwierzytelniania nie ma tradycyjnego logowania.

REST nie dyktuje żadnych zasad bezpieczeństwa, ale najczęstszą implementacją w praktyce jest OAuth z uwierzytelnianiem trójstronnym (jak już wspomniałeś w swoim pytaniu). Nie ma logowania jako takiego, przynajmniej Nie przy każdym żądaniu API. Z 3-way auth, wystarczy użyć tokenów.

    Użytkownik zatwierdza klienta API i udziela pozwolenia na składanie żądań w postaci długotrwałego tokena.]}
  1. klient Api uzyskuje krótkotrwały token, używając długotrwałego.
  2. klient Api wysyła krótkotrwały token do każdego żądania.

Ten schemat daje użytkownikowi możliwość odwołania dostępu w dowolnym momencie. Praktycznie wszystkie publicznie dostępne API RESTful jakie widziałem używają OAuth do implementacji to.

Po prostu uważam, że nie powinieneś ramkować swojego problemu (i pytania) w kategoriach logowania, ale raczej myśleć o zabezpieczeniu API w ogóle.

Aby uzyskać więcej informacji na temat uwierzytelniania API REST w ogóle, możesz zajrzeć do następujących zasobów:

 39
Author: Slavo,
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
2017-05-23 11:54:57

Dużą częścią filozofii REST jest wykorzystanie jak największej liczby standardowych funkcji protokołu HTTP podczas projektowania interfejsu API. Stosując tę filozofię do uwierzytelniania, klient i serwer wykorzystywaliby standardowe funkcje uwierzytelniania HTTP w API.

Ekrany logowania są świetne dla przypadków użycia użytkownika: odwiedź ekran logowania, podaj użytkownika/Hasło, Ustaw plik cookie, Klient zapewnia ten plik cookie we wszystkich przyszłych żądaniach. Ludzi korzystających z przeglądarek internetowych nie można oczekiwać, aby zapewnić identyfikator użytkownika i hasło przy każdym pojedynczym żądaniu HTTP.

Ale w przypadku REST API ekran logowania i pliki cookie sesji nie są bezwzględnie konieczne, ponieważ każde żądanie może zawierać dane uwierzytelniające bez wpływu na ludzkiego użytkownika; a jeśli klient nie będzie współpracował w dowolnym momencie, może zostać udzielona "nieautoryzowana" odpowiedź 401. RFC 2617 opisuje obsługę uwierzytelniania w HTTP.

TLS (HTTPS)byłby również opcją i umożliwiłby uwierzytelnienie klienta na serwerze (i vice versa) w każdym wniosku poprzez weryfikację klucza publicznego drugiej strony. Dodatkowo zabezpiecza kanał na bonus. Oczywiście konieczna jest wymiana pary klawiszy przed komunikacją. (Uwaga, dotyczy to w szczególności identyfikacji / uwierzytelniania użytkownika za pomocą TLS. Zabezpieczenie kanału za pomocą TLS / Diffie-Hellman jest zawsze dobrym pomysłem, nawet jeśli nie identyfikujesz użytkownika po jego kluczu publicznym.)

Przykład: załóżmy, że token OAuth jest Twoim pełnym loginem poświadczenia. Gdy Klient ma token OAuth, może on być dostarczony jako identyfikator użytkownika w standardowym uwierzytelnianiu HTTP przy każdym żądaniu. Serwer może zweryfikować token przy pierwszym użyciu i buforować wynik kontroli z time-To-live, który jest odnawiany przy każdym żądaniu. Każde żądanie wymagające uwierzytelnienia zwraca 401, jeśli nie zostało dostarczone.

 22
Author: wberry,
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-12-19 17:51:26