OAuth 2.0 dla komputerów stacjonarnych i aplikacji mobilnych

Question

Robię badania na temat protokołu OAuth 2.0.

Wpadłem w problem generowania tokenów okaziciela dla aplikacji komputerowych/mobilnych, które nie działają na serwerze sieciowym.

Przepływ protokołu OAuth 2.0 jest dla mnie zrozumiały dla aplikacji internetowych. Załóżmy, że myapp.com chce uzyskać dostęp do protectedresource.com w imieniu użytkownika Alice, a następnie Alice zostaje przekierowana do https://protectedresource.com/oauth?redirect_uri=https://myapp.com/oauth&[...], więc menedżer zasobów, po uzyskaniu zgody, przekierowuje przeglądarkę Alicji na stronę, która zbiera kod autoryzacyjny i używa go do uzyskania tokena okaziciela.

To działa prawidłowo i bezpieczne, ponieważ protectedresource.com rozpoznaje myapp.com domenę i zwalnia płatnika żeton tylko na żądania pochodzące z myapp.com

Jeśli biegnę aplikacji pulpitu, nawet przy wsparciu przeglądarce (tj osadzić przeglądarkę HTML w formularzu Windows lub coś podobnego) gdzie mam przekierować Alice po wyrażeniu zgody?

Kto zbiera kod autoryzacji? Jak zmienia się przepływ sterowania?

Czy ktoś ma przykłady implementacji OAuth 2.0 na komputerze lub systemie Android?

Answer 1

Możesz użyć OAuth wiki lists numerous options, z których wszystkie mają wady. Najprostszy z nich polega na uruchomieniu aplikacji internetowej, która może wyświetlić token użytkownikowi, a następnie użytkownik kopiuje token (i może token odświeżania) do aplikacji komputerowej.

Jeśli masz dużo czasu, możesz zbadać rejestrację niestandardowego identyfikatora URI przy użyciu komputerowego systemu operacyjnego, a następnie użyć go jako redirect_uri, aby automatycznie przesłać z powrotem do aplikacji z przeglądarki. Ma to najlepsze wrażenia użytkownika.

Złośliwa aplikacja może z łatwością udawać, że jest to aplikacja komputerowa w tych scenariuszach, a bezpieczeństwo zależy od tego, czy użytkownicy nie instalują złośliwych aplikacji.