Jak zabezpieczyć usługi sieciowe RESTful?

Muszę zaimplementować bezpieczne usługi sieciowe RESTful . Zrobiłem już pewne badania za pomocą Google, ale utknąłem.

Opcje:

TLS (HTTPS) +

• Podstawowy HTTP (pc1oad1etter)
• HTTP Digest
• dwuetapowa autoryzacja OAuth
• podejście oparte na plikach cookie
• certyfikaty klientów (Tom Ritter i tutaj )
• Podpisane żądania przy użyciu HMAC i ograniczony czas życia

Czy jest więcej możliwych opcji do rozważenia? Jeśli OAuth, to jaka wersja? Czy to w ogóle ma znaczenie? Z tego, co przeczytałem do tej pory, OAuth 2.0 z tokenami okaziciela (czyli bez podpisów) wydaje się być niepewny .

Znalazłem kolejny bardzo interesujący artykuł na temat uwierzytelniania opartego na REST .

Zabezpiecz swój interfejs API REST ... we właściwy sposób

Jest inna, bardzo bezpieczna metoda. To certyfikaty klienta. Wiesz, w jaki sposób serwery prezentują certyfikat SSL, gdy kontaktujesz się z nimi przez https? Cóż, serwery mogą zażądać certyfikatu od klienta, aby wiedzieć, że klient jest tym, za kogo się podaje. Klienci generują certyfikaty i przekazują je za pośrednictwem bezpiecznego kanału (np. Przychodząc do biura z kluczem USB - najlepiej niezainfekowanym kluczem USB).

Ładujesz klucz publiczny certyfikatów klienta certyfikatów (i certyfikatów ich osoby podpisującej, jeśli to konieczne) na serwer sieciowy, a serwer sieciowy nie będzie akceptował połączeń od nikogo poza osobami, które mają odpowiednie klucze prywatne do certyfikatów to wie. Działa na warstwie HTTPS, więc możesz nawet całkowicie pominąć uwierzytelnianie na poziomie aplikacji, takie jak OAuth (w zależności od wymagań). Możesz oddzielić warstwę i utworzyć lokalny urząd certyfikacji oraz podpisywać żądania certyfikatów od klientów, co pozwala pominąć kroki „spraw, aby przyszli do biura” i „załaduj certyfikaty na serwer”.

Ból szyi? Absolutnie. Dobry na wszystko? Nie. Bardzo bezpieczne? Tak.

Opiera się jednak na tym, że klienci dbają o bezpieczeństwo swoich certyfikatów (nie mogą publikować swoich kluczy prywatnych online) i jest zwykle używany, gdy sprzedajesz usługę klientom, zamiast pozwalać każdemu zarejestrować się i połączyć.

W każdym razie może to nie być rozwiązanie, którego szukasz (prawdopodobnie nie jest to szczere), ale to inna opcja.

HTTP Basic + HTTPS to jedna z powszechnych metod.

Jeśli wybierasz między wersjami OAuth, wybierz OAuth 2.0.

Tokenów na okaziciela OAuth należy używać tylko z bezpiecznym transportem.

Tokeny okaziciela OAuth są tak bezpieczne lub niepewne, jak transport, który szyfruje konwersację. HTTPS dba o ochronę przed powtórkowymi atakami, więc nie jest konieczne, aby token okaziciela również chronił przed powtórzeniem.

Chociaż prawdą jest, że jeśli ktoś przechwyci twój token okaziciela, może podszyć się pod Ciebie podczas wywoływania interfejsu API, istnieje wiele sposobów na ograniczenie tego ryzyka. Jeśli dasz swoim tokenom długi okres wygaśnięcia i oczekujesz, że Twoi klienci będą przechowywać tokeny lokalnie, masz większe ryzyko przechwycenia tokenów i ich niewłaściwego wykorzystania niż w przypadku, gdy nadasz swoim tokenom krótki okres ważności, wymagaj od klientów nabycia nowych tokenów na każdą sesję, i doradzaj klientom, aby nie utrwalali tokenów.

Jeśli potrzebujesz zabezpieczyć ładunki, które przechodzą przez wielu uczestników, potrzebujesz czegoś więcej niż HTTPS / SSL, ponieważ HTTPS / SSL szyfruje tylko jedno łącze wykresu. To nie jest wina protokołu OAuth.

Tokeny okaziciela są łatwe do uzyskania dla klientów, łatwe w użyciu dla klientów do wywołań API i są szeroko stosowane (z HTTPS) do zabezpieczania publicznych interfejsów API z Google, Facebooka i wielu innych usług.