Wzorzec logowania do interfejsu API REST

Tworzę REST api, ściśle przestrzegając sugestii apigee, używając rzeczowników, a nie czasowników, wersji API zapieczętowanej w adresie URL, dwóch ścieżek API na kolekcję, użycie GET POST PUT DELETE itp.

Pracuję nad systemem logowania, ale nie mam pewności co do prawidłowego sposobu logowania użytkowników REST. W tym momencie nie pracuję nad bezpieczeństwem, tylko nad wzorcem logowania lub przepływem. (Później dodamy 2-stopniową OAuth, z HMAC itp.)

Możliwe opcje

• POST do czegoś w rodzaju https://api...com/v1/login.json
• PUT na coś takiego https://api...com/v1/users.json
• Coś, o czym nie pomyślałem ...

Jaki jest właściwy styl REST do logowania użytkowników?

Principled Design of the Modern Web Architecture autorstwa Roya T. Fieldinga i Richarda N. Taylora , czyli sekwencja prac z całej terminologii REST, zawiera definicję interakcji klient-serwer:

Wszystkie interakcje REST są bezpaństwowe . Oznacza to, że każde żądanie zawiera wszystkie informacje niezbędne łącznikowi do zrozumienia żądania, niezależnie od wszelkich żądań, które mogły je poprzedzać .

To ograniczenie spełnia cztery funkcje, pierwsza i trzecia są ważne w tym konkretnym przypadku:

• Po pierwsze : eliminuje potrzebę zachowania przez łączniki stanu aplikacji między żądaniami , zmniejszając w ten sposób zużycie zasobów fizycznych i poprawiając skalowalność;
• Po trzecie : umożliwia pośrednikowi przeglądanie i rozumienie żądania oddzielnie , co może być konieczne, gdy usługi są dynamicznie rearanżowane;

A teraz wróćmy do twojego zabezpieczenia. Każde żądanie powinno zawierać wszystkie wymagane informacje, a autoryzacja / uwierzytelnienie nie jest wyjątkiem. Jak to osiągnąć? Dosłownie wysyłaj wszystkie wymagane informacje przez przewody z każdym żądaniem.

Jednym z przykładów, jak to zrobić, jest kod uwierzytelniania wiadomości oparty na skrócie lub HMAC . W praktyce oznacza to dodawanie skrótu aktualnej wiadomości do każdego żądania. Kod skrótu obliczany przez kryptograficzną funkcję skrótu w połączeniu z tajnym kluczem kryptograficznym . Kryptograficzna funkcja skrótu jest predefiniowana lub stanowi część koncepcji REST kodu na żądanie (na przykład JavaScript). Tajny klucz kryptograficzny powinien być dostarczony przez serwer do klienta jako zasób, a klient używa go do obliczenia kodu skrótu dla każdego żądania.

Istnieje wiele przykładów implementacji HMAC , ale chciałbym, abyś zwrócił uwagę na następujące trzy:

• Uwierzytelnianie żądań REST dla usługi Amazon Simple Storage (Amazon S3)
• Odpowiedź Mauricelessa na quiestion: „Jak zaimplementować uwierzytelnianie HMAC w RESTful WCF API”
• crypto-js: implementacje JavaScript standardowych i bezpiecznych algorytmów kryptograficznych

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 stanu 307 Tymczasowe przekierowanie) w celu autoryzacji i uzyskania tajnego klucza, a następnie przekierowany z powrotem do oryginalnego zasobu. W tym przypadku nie ma potrzeby wcześniejszej znajomości (tj. Gdzieś na stałe zakodować), jaki jest adres URL do autoryzacji klienta i można z czasem dostosować ten schemat.

Mam nadzieję, że pomoże Ci to znaleźć właściwe rozwiązanie!

TL; DR Logowanie dla każdego żądania nie jest wymaganym elementem do implementacji bezpieczeństwa API, ale uwierzytelnianie jest.

Trudno odpowiedzieć na pytanie dotyczące logowania, nie mówiąc ogólnie o bezpieczeństwie. W przypadku niektórych schematów uwierzytelniania nie ma tradycyjnego logowania.

REST nie narzuca żadnych reguł bezpieczeństwa, ale w praktyce najczęściej stosowaną implementacją jest OAuth z uwierzytelnianiem trójstronnym (jak wspomniałeś w swoim pytaniu). Nie ma logowania jako takiego, przynajmniej nie przy każdym żądaniu API. W przypadku uwierzytelniania trójstronnego po prostu używasz tokenów.

1. Użytkownik zatwierdza klienta API i udziela uprawnień do wysyłania żądań w postaci tokenu o długiej żywotności
2. Klient API uzyskuje krótkotrwały token przy użyciu długowiecznego.
3. Klient API wysyła krótkotrwały token z każdym żądaniem.

Ten schemat daje użytkownikowi możliwość cofnięcia dostępu w dowolnym momencie. Praktycznie wszystkie publicznie dostępne interfejsy API RESTful, które widziałem, używają protokołu OAuth do implementacji tego.

Po prostu nie uważam, że powinieneś ująć swój problem (i pytanie) w kategoriach logowania, ale raczej pomyśleć o ogólnym zabezpieczeniu API.

Więcej informacji na temat ogólnego uwierzytelniania interfejsów REST API można znaleźć w następujących zasobach:

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• Uwierzytelnianie REST API
• Uwierzytelnianie RESTful API

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 wykorzystywałyby standardowe funkcje uwierzytelniania HTTP w API.

Ekrany logowania świetnie sprawdzają się w przypadku użytkowników: odwiedź ekran logowania, podaj użytkownika / hasło, ustaw plik cookie, klient zapewnia ten plik cookie we wszystkich przyszłych żądaniach. Nie można oczekiwać, że ludzie używający przeglądarek internetowych będą podawać identyfikator użytkownika i hasło przy każdym indywidualnym żądaniu HTTP.

Jednak w przypadku interfejsu API REST ekran logowania i pliki cookie sesji nie są bezwzględnie konieczne, ponieważ każde żądanie może zawierać poświadczenia bez wpływu na użytkownika; a jeśli klient nie współpracuje w dowolnym momencie, 401można udzielić „nieautoryzowanej” odpowiedzi. RFC 2617 opisuje obsługę uwierzytelniania w protokole HTTP.

TLS (HTTPS) byłby również opcją i pozwoliłby na uwierzytelnianie klienta na serwerze (i odwrotnie) w każdym żądaniu poprzez weryfikację klucza publicznego drugiej strony. Dodatkowo zapewnia to kanałowi premię. Oczywiście, aby to zrobić, konieczna jest wymiana pary kluczy przed komunikacją. (Uwaga: dotyczy to w szczególności identyfikacji / uwierzytelniania użytkownika za pomocą protokołu TLS. Zabezpieczanie kanału za pomocą protokołu TLS / Diffie-Hellman jest zawsze dobrym pomysłem, nawet jeśli nie identyfikujesz użytkownika za pomocą jego klucza publicznego).

Przykład: załóżmy, że token OAuth to Twoje pełne dane logowania. Gdy klient ma token OAuth, można go podać jako identyfikator użytkownika w standardowym uwierzytelnianiu HTTP przy każdym żądaniu. Serwer może zweryfikować token przy pierwszym użyciu i zapisać wynik sprawdzenia w pamięci podręcznej z czasem wygaśnięcia, który jest odnawiany przy każdym żądaniu. Każde żądanie wymagające uwierzytelnienia jest zwracane, 401jeśli nie zostanie podane.