Przepływ OAuth2 - czy serwer sprawdza poprawność na serwerze Auth?

10

Dużo czytałem na temat OAuth2, próbując obejść ten problem, ale wciąż jestem z czegoś zdezorientowany.

Rozumiem, że klient autoryzuje się u dostawcy OAuth (na przykład Google) i zezwala serwerowi zasobów na dostęp do danych profilu użytkownika. Następnie klient może wysłać token dostępu do serwera zasobów i zwrócić mu zasób.

Ale to, co nie wydaje się być objęte żadną dokumentacją, dzieje się, gdy aplikacja kliencka prosi serwer zasobów o zasób i przekazuje mu token dostępu. Wszystko, co przeczytałem do tej pory, mówi, że serwer zasobów odpowiada tylko żądanym zasobem.

Ale to wydaje się być wielką dziurą, na pewno serwer zasobów musi w jakiś sposób sprawdzić poprawność tokena dostępu, w przeciwnym razie mógłbym po prostu sfałszować każde stare żądanie i przekazać stary, skradziony, fałszywy lub losowo wygenerowany token i po prostu go zaakceptowałby.

Czy ktoś może wskazać mi proste wyjaśnienie OAuth2, ponieważ jak dotąd te, które przeczytałem, wydają się niekompletne.

security oauth2

— drekka
źródło

8

Znaleziono to. Pochowany w specyfikacji. Mówią, że serwer zasobów powinien sprawdzić poprawność tokena dostępu z serwerem autoryzacji, ale jest to poza zakresem dokumentu. Szkoda, pomyślałbym, że walidacja tokena jest ważną częścią.

— drekka
źródło

1

O ważnych częściach warto przeczytać ten post na blogu, aby zapoznać się z priorytetami OAuth2.

— Lars Viklund,

1

Dzięki za ciekawą lekturę. Moje wymagania są raczej proste, ponieważ chcę zezwolić aplikacji iOS na uwierzytelnianie się za pomocą Google, Twittera, Facebooka itp., Przekazywanie jakiejś formy autoryzacji na mój serwer i sprawdzanie go przez serwer oraz umożliwienie dostępu do zasobów. Problem okazał się bardziej złożony niż się spodziewałem ze względu na złożoność zrozumienia, jak to działa i co muszę zrobić gdzie.

— drekka

Mówiąc dokładniej, dodatek A: „Aby sprawdzić poprawność podpisu na żądanie, chroniony zasób może być w stanie przesłać identyfikator tokena do punktu końcowego introspekcji serwera autoryzacji, aby uzyskać niezbędne kluczowe informacje potrzebne do tego tokena. Szczegóły tego użycia są poza zakres tej specyfikacji zostanie określony w rozszerzeniu [...] ”.

— JulienD

2

Sprawdzanie poprawności tokenów jest zazwyczaj obsługiwane na 1 z 2 sposobów.

1) Token jest podpisany kryptograficznie przy użyciu wstępnie udostępnionych kluczy. Ma to oczywiste braki w stosowaniu w rozproszonych, proliferujących systemach.

2) Serwer autoryzacji (AS) zapewnia punkt końcowy dla sprawdzania poprawności tokenu lub introspekcji. Ta metoda została znormalizowana w IETF RFC 7662 w październiku 2015 r., Patrz: https://tools.ietf.org/html/rfc7662

Pytanie / odpowiedź na pytanie o przepełnienie stosu zawiera przykłady od Google i Github: /programming/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server

— Howie Ross
źródło

0

czytasz specyfikację dotyczącą sprawdzania poprawności tokena:

https://tools.ietf.org/html/rfc7662

mam nadzieję, że to pomoże - zaznacz odpowiedź, jeśli odpowiada na twoje zapytanie / problem

— Chirag
źródło

4

Witamy w inżynierii oprogramowania. W obecnej formie odpowiedź ta nie spełnia naszych wytycznych dotyczących jakości . Oczekujemy, że odpowiedzi powinny stać na własną rękę - czytelnicy powinni podążać za linkami zewnętrznymi tylko po to, aby uzyskać głębsze zrozumienie lub potwierdzić źródła, a odpowiednią treść należy cytować tutaj.

— Thomas Owens