Jak i dlaczego przeprowadza się weryfikację tokenów Google OAuth?

Google odnosi się konkretnie do tokena access .

W kontekście OAuth 2.0 problem confused deputy dotyczy Implicit Grant protocol flow , gdy jest używany do uwierzytelniania . To, co Google nazywa "OAuth 2.0 Dla aplikacji po stronie klienta", opiera się na niejawnym przepływie protokołu dotacji.

Ponieważ implicit Flow ujawnia token dostępu użytkownikowi końcowemu poprzez fragment URI, wprowadza możliwość, że token dostępu może być majstrowanym. Legalna aplikacja (klient OAuth) może stać się zdezorientowanym zastępcą, akceptując token dostępu, który został wydany innej (złośliwej) aplikacji, dając w ten sposób atakującemu dostęp do konta ofiary.

Krytycznym krokiem w walidacji tokenu dostępu jest sprawdzenie przez aplikację, czy token dostępu nie został pierwotnie wydany innej aplikacji. Google zwraca na to uwagę, gdy mówią :

Uwaga: podczas weryfikacji tokena ważne jest, aby upewnij się, że pole odbiorców w odpowiedzi dokładnie odpowiada identyfikatorowi client_id zarejestrowanemu w konsoli API. Jest to złagodzenie problemu zdezorientowanego zastępcy, a wykonanie tego kroku jest absolutnie niezbędne.

Jako uproszczony przykład, wyobraź sobie, że istnieją dwie aplikacje: (1) FileStore, legalna aplikacja do przechowywania plików i (2) EvilApp. Obie aplikacje wykorzystują proces uwierzytelniania Google dla aplikacji po stronie klienta. Alice jest niewinnym użytkownikiem końcowym, a jej identyfikator użytkownika Google to XYZ.

1. Alice Zaloguj się do FileStore za pomocą Google.
2. Po procesie auth FileStore tworzy konto Alice i kojarzy je z Google user ID XYZ.
[23]} Alice wgrywa kilka plików na swoje konto FileStore. Jak na razie wszystko jest w porządku. [23]}później, Alice podpisuje się do EvilApp, który oferuje gry, które wyglądają trochę zabawy. W rezultacie EvilApp otrzymuje token dostępu, który jest powiązany z Google user ID XYZ.
3. właściciel EvilApp może teraz skonstruować URI przekierowania dla FileStore, wstawiając token dostępu, który został wydany dla konta Google Alicji.
4. atakujący łączy się z FileStore, który pobierze token dostępu i sprawdzi w Google, dla którego użytkownika jest. Google powie, że to użytkownik XYZ.
5. FileStore da atakującemu dostęp do plików Alice, ponieważ atakujący ma token dostępu dla użytkownika Google XYZ.

Błąd FileStore polegał na tym, że nie sprawdzał w Google, czy dany token dostępu był naprawdę wydany do FileStore; token został naprawdę wydany do EvilApp.

Inni opisali to znacznie bardziej elegancko niż ja:

• http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• http://tools.ietf.org/html/rfc6749#section-10.16

Mam nadzieję, że to wyjaśnia Dlaczego {[2] } część walidacji tokena dostępu z aplikacjami po stronie klienta, oraz jak odnosi się to do problemu dezorientacji.