Jak używać OpenID lub OAuth do wewnętrznego uwierzytelniania wewnętrznego?

Question

Pracuję nad wewnętrznym systemem uwierzytelniania dla użytkowników zestawu aplikacji internetowych RESTful. Naszym zamiarem jest, aby użytkownik mógł być zalogowany przez formularz internetowy i mieć odpowiedni dostęp do wszystkich aplikacji RESTful w naszej domenie, które mogą być dystrybuowane w prywatnej chmurze na wielu serwerach. (Rozumiem, że posiadanie pojedynczej sesji uwierzytelnionej nie jest zgodne z czystym podejściem REST, ale jest to wymóg użyteczności.)

Same aplikacje będą napisane w różnych językach programowania, więc podejście neutralne językowo jest wymagany. Zasugerowano mi, że możemy wykorzystać OpenID lub OAuth lub podobną platformę do obsługi uwierzytelniania, ale mam świadomość, że są one przeznaczone dla usług stron trzecich, a nie z własnych usług, które udostępniają dane w naszym wewnętrznym systemie. W takim przypadku możemy mieć centralną usługę dostawcy z wszystkimi innymi aplikacjami traktowanymi jako strony trzecie (lub strony ufające).

Pytania:

1. Czy OpenID/OAuth nadaje się do uwierzytelniania między usługami pierwszej partii?
2. W takim razie, w jaki sposób należy ustawić uwierzytelnianie dla tego przypadku użycia?
3. Czy użytkownik nie musiałby udzielać indywidualnego pozwolenia każdemu serwerowi, z którego chciał korzystać, tak samo jak musiałby udzielić indywidualnego pozwolenia dowolnemu zewnętrznemu serwerowi? Myślę, że naruszyłoby to wymóg posiadania pojedynczego logowania na dostęp do wszystkich usług własnych.
4. Czy istnieją dobre przykłady witryn wspierających ten przypadek użycia?
5. Jakie byłyby dobre alternatywne ramy dla tego zastosowania?

Answer 1

Nie potrzebujesz OAuth do usług SSO.

Podstawowym zastosowaniem/zaletą protokołu OAuth jest, jak już wiesz, przyznanie dostępu do aplikacji innej firmy w celu uzyskania dostępu do/korzystania z zasobu w kontrolowany sposób.

Zamiast posiadania serwera uwierzytelniania/autoryzacji, który byłby potrzebny w OAuth, może warto skorzystać z pojedynczej usługi logowania dla wszystkich interfejsów API. Token dostępu OAuth różni się od tego, czego potrzebujesz.

O ile rozumiem, to, co możesz mieć, to coś w rodzaju OAuth w taki sposób, że twój serwer sprzedaje tokeny do aplikacji. (Zakładam, że jest to całkowicie wewnętrzny system, więc tokenów nie można nadużywać).

Więc w zasadzie co ja proponuje to:

1. Kiedy aplikacja próbuje uzyskać dostęp do pierwszej API to przekierowany do formularza internetowego.
2. Użytkownik wprowadza poświadczenia i jest kierowany do bazy danych w celu weryfikacji.Niech będzie usługa generująca token dla użytkownika/aplikacji
3. Następujące żądanie dostępu do interfejsu API zostanie utworzone za pomocą tokena - token jednoznacznie identyfikuje aplikację
4. W zależności od wymaganego poziomu zabezpieczeń możesz podpisać tekst używając HMAC i wysłać go jako token, lub jeśli jest całkowicie wewnętrzny, po prostu wygeneruj unikalny identyfikator dla aplikacji/użytkownika i wyślij go do innego API
5. Po otrzymaniu tokena każda usługa najpierw wywołuje serwer główny z tokenem i wewnętrznie pobiera odpowiedni identyfikator klienta/użytkownika i wykonuje wymaganą funkcję.

W skrócie oddziel od weryfikacji token + token generowania tokena do innego modułu. Wszystkie interfejsy API powinny używać tego modułu do weryfikacji logowania/tokena.

To, co tu zaproponowałem, działa jak OAuth, ale wszystkie aspekty bezpieczeństwa zostały usunięte, ponieważ chcesz używać go w prywatnej chmurze.

Answer 2

Oauth obsługuje wiele różnych rodzajów przepływów. Możesz użyć przepływu kreacji klienta z Oauth 2.0, aby uniknąć pytania o zezwolenie dla każdej aplikacji (jest to przeznaczone dla przypadków, w których kontrolujesz zarówno serwer, jak i aplikację lub gdzie chcesz wstępnie autoryzować określone aplikacje). Ten post dobrze wyjaśnia wszystko: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/