Dwunożny OAuth - poszukuje informacji

głosy
25

Chcę wdrożyć nową REST oparte API naszej infrastruktury i OAuth wydaje się być droga.

Dla naszych realizacji, nie będzie po prostu być pierwszy serwer-serwer dostępu, który będzie całkowicie nieograniczone. Wierzę, że to się nazywa dwunożny autoryzacji.

Później chcielibyśmy umożliwić API do spożycia przez przeglądarkę, która zamieni nasz zezwolenia na trzech nogach.

Czy jest to dobry punkt wyjścia do realizacji tego? W jaki sposób możemy w pełni autoryzować serwer iw dół drogi dodać ograniczonego zezwolenia na użytkownika?

Specyfikacja OAuth nie jest bardzo pomocne w takich sytuacjach, ale wierzę, że to oznacza, że ​​trzeba utworzyć nigdy nie wygasa sesji dla dostępu serwer-serwer, a później dodać normalne sesje z ograniczonym dostępem do interfejsów API dla użytkownika tylko.

Mam nadzieję znaleźć punkty zaczynające uzyskać więcej informacji, daj mi znać!

OAuth jest dla mnie? Ja tylko szukam uwierzytelnionego systemu żądanie i tylko konsument i usługodawcą istnieje w tym scenariuszu. Użytkownik końcowy nie wchodzi w grę!

Utwórz 19/05/2009 o 21:46
źródło użytkownik
W innych językach...                            


3 odpowiedzi

głosy
48

Ya, OAuth jest prawdopodobnie dla ciebie.

Są to właściwie dwa specyfikacji OAuth, 3-nogami wersja i wersja 2 nogami. Wersja 3-nogami jest ten, który dostaje najwięcej uwagi, a to nie ten, który chcesz użyć.

Dobrą wiadomością jest to, że wersja 2 nogami robi dokładnie to, co chcesz, umożliwia aplikacja do udzielenia dostępu do drugiego za pośrednictwem obu wspólnego klucza tajnego (bardzo podobny do Web modelu obsługi Amazon, można użyć metody podpisywania HMAC-SHA1) lub za pośrednictwem systemu publicznego / prywatnego klucza (stosowanie metody podpisywania RSA-SHA1). Złą wiadomością jest to, że to nie tak dobrze jeszcze obsługiwane jak w wersji 3-nogach jeszcze, więc być może trzeba będzie zrobić trochę więcej pracy niż w przeciwnym razie może mieć do teraz.

Zasadniczo, 2-autoryzacji OAuth tylko określa sposób na „znak” (obliczyć hash over) kilka pól, które zawierają aktualną datę, liczbę losową o nazwie „nonce” i parametry żądania. To sprawia, że bardzo trudno personifikować żądania do usługi internetowej.

OAuth jest powoli, ale staje się akceptowanym standardem dla tego typu rzeczy - będziesz najlepszy w dłuższej perspektywie, jeśli go objąć, bo ludzie mogą następnie wykorzystać różne dostępne dla bibliotek robić.

To bardziej skomplikowane niż mogłoby się początkowo chcą dostać się - ale dobrą wiadomością jest to, że wiele osób poświęca wiele czasu na to, aby wiedzieć, że nie mają nic zapomniane. Doskonałym przykładem jest to, że bardzo niedawno Twitter znalazł lukę bezpieczeństwa OAuth, których Wspólnota jest obecnie pracuje na zamknięciu. Gdybyś wynalazł swój własny system, masz, aby dowiedzieć się tego wszystkiego na własną rękę.

Powodzenia!

Odpowiedział 06/06/2009 o 08:02
źródło użytkownik

głosy
5

Pamiętaj, aby odróżnić uwierzytelniania i autoryzacji. W niektórych miejscach, wierzę, że PO miesza dwa.

Na przykład, gdy serwer uwierzytelnia kogoś, to zwykle bezpośrednio lub pośrednio (za pomocą plików cookie) zapewnia tokenu uwierzytelniania tak, że kolejne wnioski są już dozwolone.

To zależy od serwera, jak długo poświadczenia ostatni. Jest inteligentny, aby zaplanować , że poświadczenia zostanie time-out w pewnym momencie. Wystarczy mieć serwer klient być przygotowany do ponownego uwierzytelnienia się, gdy tylko otrzyma „zezwolenie wygasło” odpowiedź o błędzie.

Nie chcesz, aby spróbować zapewnić „nigdy nie wygasa” Sesja od:

  1. Wszystko wygasa w pewnym momencie. Na przykład, w jaki sposób klient-serwer móc rozpocząć dostępu aplikację ponownie, jeśli straci moc lub zostanie uruchomiony ponownie?

  2. Tworząc system nieelastyczne. Mają tendencję do częstszego złamać.

  3. Skoro wiesz, że chcesz dodać dodatkowe typy logowania w przyszłości, zamiast dwóch rodzajów logowań (klientów serwerów i klientów przeglądarce) dokonać tylko jeden typ logowania teraz. Dodatkowa praca dla serwera klient będzie wdrożyć „ponowne logowanie jako konieczne” zdolności.
Odpowiedział 19/05/2009 o 22:02
źródło użytkownik

głosy
2

OAuth skończy się zbyt trudne dla naszych potrzeb. Zdecydowałem się przyjąć schemat uwierzytelniania Amazon S3, wystarczy, ponieważ nasz model pasuje lepiej.

Dzięki za pomoc znalezienia odpowiedzi chociaż ..

Odpowiedział 10/06/2009 o 21:49
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more