Logowanie jednokrotne z CAS lub OAuth?

186

Zastanawiam się, czy powinienem używać protokołu CAS lub OAuth + jakiegoś dostawcy uwierzytelniania do pojedynczego logowania.

Przykładowy scenariusz:

  1. Użytkownik próbuje uzyskać dostęp do chronionego zasobu, ale nie jest uwierzytelniony.
  2. Aplikacja przekierowuje użytkownika na serwer SSO.
  3. W przypadku uwierzytelnienia użytkownik otrzymuje token z serwera SSO.
  4. SSO przekierowuje do oryginalnej aplikacji.
  5. Oryginalna aplikacja sprawdza token na serwerze SSO.
  6. Jeśli token jest prawidłowy, dostęp zostanie udzielony, a aplikacja będzie znała identyfikator użytkownika.
  7. Użytkownik dokonuje wylogowania i zostaje wylogowany ze wszystkich połączonych aplikacji w tym samym czasie (wylogowanie jednokrotne).

O ile rozumiem, właśnie po to został wymyślony CAS. Klienci CAS muszą zaimplementować protokół CAS, aby korzystać z usługi uwierzytelniania. Teraz zastanawiam się nad używaniem CAS lub OAuth w witrynie klienta (konsumenta). Czy OAuth zastępuje tę część CAS? Czy należy preferować OAuth jako nowy faktyczny standard? Czy istnieje łatwy w użyciu (nie Sun OpenSSO!) Zamiennik części uwierzytelniającej CAS obsługujący różne metody, takie jak nazwa użytkownika / hasło, OpenID, certyfikaty TLS ...?

Kontekst:

  • Różne aplikacje powinny polegać na uwierzytelnianiu serwera SSO i powinny używać czegoś podobnego do sesji.
  • Aplikacje mogą być aplikacjami sieciowymi GUI lub usługami (REST).
  • Serwer SSO musi mieć identyfikator użytkownika, który jest niezbędny, aby uzyskać więcej informacji o użytkowniku, takich jak role, poczta e-mail itp. Z centralnego magazynu informacji o użytkowniku.
  • Pojedyncze wylogowanie powinno być możliwe.
  • Większość klientów jest napisana w języku Java lub PHP.

Właśnie odkryłem WRAP , który może zostać następcą protokołu OAuth. Jest to nowy protokół określony przez Microsoft, Google i Yahoo.

Uzupełnienie

Dowiedziałem się, że OAuth nie został zaprojektowany do uwierzytelniania, nawet może być używany do implementacji SSO, ale tylko razem z usługą SSO, taką jak OpenID.

Wydaje mi się, że OpenID to „nowy CAS”. CAS ma pewne funkcje, które pomija OpenID (takie jak pojedyncze wylogowanie), ale dodanie brakujących części w określonym scenariuszu nie powinno być trudne. Myślę, że OpenID ma szeroką akceptację i lepiej jest zintegrować OpenID z aplikacjami lub serwerami aplikacji. Wiem, że CAS obsługuje również OpenID, ale myślę, że CAS jest zbędny w przypadku OpenID.

security  oauth  single-sign-on  cas 
— demon
źródło
6
Pojedyncze wylogowanie jest antyfunkcją. Wszystkie badania użytkowników, o których wiem, że je obejmowały, wykazały, że jest to od łagodnego do skrajnie zagmatwanego, zarówno dla początkujących, jak i zaawansowanych użytkowników. Osobiście muszę korzystać z systemu, który codziennie korzysta z pojedynczego wylogowania i jest to dla mnie niezwykle irytujące. Prawie nigdy tego nie chcę.
— Bob Aman,
16
Nie zgadzaj się, że pojedyncze wylogowanie jest antyfakturą. Wszystko zależy od aplikacji, o których mowa. W przypadku aplikacji internetowych, które w jakiś sposób są ze sobą powiązane, np. Poczta Google i kalendarz Google, sensowne jest, aby wylogować się jawnie z jednego, wylogować się z drugiego. W przypadku aplikacji, w których nie ma widocznego „związku”, zgadzam się z Bobem.
— jesion
6
Pamiętaj, że to pytanie zostało pierwotnie zadane przed wprowadzeniem OAuth 2.0, więc informacje związane z OAuth mogą już nie być poprawne.
— Andrew,

Odpowiedzi:

240

OpenID nie jest „następcą” ani „substytutem” CAS, są one różne pod względem intencji i implementacji.

CAS centralizuje uwierzytelnianie. Użyj go, jeśli chcesz, aby wszystkie Twoje (prawdopodobnie wewnętrzne) aplikacje prosiły użytkowników o zalogowanie się na jednym serwerze (wszystkie aplikacje są skonfigurowane tak, aby wskazywały jeden serwer CAS).

OpenID decentralizuje uwierzytelnianie. Użyj go, jeśli chcesz, aby Twoja aplikacja akceptowała logowanie użytkowników do dowolnej usługi uwierzytelniania, jakiej chcą (użytkownik podaje adres serwera OpenID - w rzeczywistości „nazwa użytkownika” to adres URL serwera).

Żadne z powyższych nie obsługuje autoryzacji (bez rozszerzeń i / lub dostosowań).

OAuth obsługuje autoryzację, ale nie zastępuje tradycyjnej „tabeli USER_ROLES” (dostęp użytkownika). Obsługuje autoryzację stron trzecich.

Na przykład chcesz, aby Twoja aplikacja była zintegrowana z Twitterem: użytkownik może pozwolić jej na automatyczne tweetowanie, gdy aktualizuje swoje dane lub publikuje nowe treści. Chcesz uzyskać dostęp do usług lub zasobów strony trzeciej w imieniu użytkownika, bez uzyskiwania jego hasła (co jest oczywiście niebezpieczne dla użytkownika). Aplikacja prosi Twittera o dostęp, użytkownik go autoryzuje (przez Twittera), po czym aplikacja może mieć dostęp.

Tak więc OAuth nie dotyczy jednokrotnego logowania (ani nie zastępuje protokołu CAS). Nie chodzi o to, abyś kontrolował, do czego użytkownik ma dostęp. Chodzi o umożliwienie użytkownikowi kontrolowania sposobu, w jaki osoby trzecie mogą uzyskać dostęp do swoich zasobów. Dwa bardzo różne przypadki użycia.

W opisanym przez ciebie kontekście CAS jest prawdopodobnie właściwym wyborem.

[zaktualizowano]

To powiedziawszy, możesz zaimplementować logowanie jednokrotne z OAuth, jeśli uważasz tożsamość użytkownika za zabezpieczony zasób. Tak właśnie działa „Zarejestruj się w GitHubie” i polubienia. Prawdopodobnie nie było to pierwotne zamierzenie protokołu, ale można to zrobić. Jeśli kontrolujesz serwer OAuth i ograniczysz aplikacje do uwierzytelniania się tylko za jego pomocą, oznacza to logowanie jednokrotne.

Nie ma jednak standardowego sposobu wymuszenia wylogowania (CAS ma tę funkcję).

— tetsuo
źródło
11
Chociaż OAuth dotyczy głównie autoryzacji, może być używany tak, jakby był centralnym serwerem uwierzytelniającym. Podobnie jak sposób, w jaki konto Google OAuth jest używane przez wiele witryn (w tym SO) do uwierzytelniania, bez faktycznego korzystania z żadnej usługi dostawcy OAuth.
— Amir Ali Akbari
1
Ponadto, jak wspomniano w odpowiedzi Bertla, CAS zapewnia teraz OAuth zarówno jako klient, jak i serwer.
— Anthony O.
3
Czy ta odpowiedź jest nadal aktualna teraz, gdy istnieje OAuth 2.0? Jak zmieniła się Twoja opinia dzięki OAuth 2.0?
— Andrew,
6
OAuth 2.0 jest nadal protokołem autoryzacji, a nie protokołem uwierzytelniającym, ale można na podstawie OAuth 2.0 utworzyć protokół uwierzytelniania, tak jak zrobiły to Facebook / LinkedIn itp .; jedynym znormalizowanym rozszerzeniem OAuth 2.0, które zapewnia uwierzytelnianie, jest OpenID Connect, który jest wyznaczonym następcą OpenID
— Hans Z.
48

Myślę o tym w ten sposób:

Użyj CAS, jeśli kontrolujesz / jesteś właścicielem systemu uwierzytelniania użytkowników i potrzebujesz obsługi heterogenicznego zestawu serwerów i aplikacji, które wymagają scentralizowanego uwierzytelniania.

Użyj OAuth, jeśli chcesz obsługiwać uwierzytelnianie użytkowników z systemów, których nie jesteś właścicielem / nie obsługujesz (np. Google, Facebook itp.).

— Lance Weber
źródło
6
OpenID to protokół uwierzytelniania, OAuth to protokół autoryzacji.
— zenw0lf
13

OpenID to protokół uwierzytelniania, OAuth i OAuth WRAP to protokoły autoryzacyjne. Można je łączyć z hybrydowym rozszerzeniem OpenID .

Zdecydowanie wolałbym, aby ludzie budowali na najwyższych standardach, które mają duży rozmach (bardziej dostępne wsparcie, łatwiejsze do zaangażowania strony trzecie), nawet jeśli nie są one dokładnie dopasowane do danej aplikacji. W tym przypadku OAuth ma rozpęd, a nie CAS. Powinieneś móc zrobić wszystko lub przynajmniej prawie wszystko, co musisz zrobić z OAuth. W późniejszym czasie OAuth WRAP powinien jeszcze bardziej uprościć sprawę (wymaga pewnych kompromisów, używając tokena okaziciela i przenosząc szyfrowanie do warstwy protokołu), ale nadal jest w powijakach, a tymczasem OAuth prawdopodobnie wykona pracę dobrze.

Ostatecznie, jeśli zdecydujesz się korzystać z OpenID i OAuth, będzie więcej bibliotek dla większej liczby języków dostępnych dla Ciebie i dla każdego, kto musi zintegrować się z systemem. Masz też dużo więcej gałek ocznych, które przyglądają się protokołom, upewniając się, że naprawdę są tak bezpieczne, jak powinny.

— Bob Aman
źródło
8

Dla mnie prawdziwą różnicą między SSO a OAuth jest przyznanie, a nie uwierzytelnianie, ponieważ serwer, który implementuje OAuth, oczywiście ma uwierzytelnianie (musisz być zalogowany do Google, openId lub facebook, aby OAuth działało z aplikacją klienta)

W przypadku logowania jednokrotnego użytkownik zaawansowany / administrator systemu przyznaje wcześniej użytkownikowi końcowemu dostęp do aplikacji w „aplikacji logowania jednokrotnego”. W przypadku protokołu OAuth użytkownik końcowy przyznaje aplikacji dostęp do swoich „danych” w „aplikacji OAuth”

Nie rozumiem, dlaczego nie można użyć protokołu OAuth jako części serwera logowania jednokrotnego. Po prostu usuń ekran grantu z przepływu i pozwól serwerowi OAuth na wyszukanie grantu z bazy danych wspierającej.

— redben
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.