Wyjaśnienie: aplikacja mobilna = aplikacja natywna
Jak stwierdzono w innych komentarzach i kilku źródłach online, domniemanie wydaje się być naturalnym rozwiązaniem dla aplikacji mobilnych, jednak najlepsze rozwiązanie nie zawsze jest jednoznaczne (i w rzeczywistości nie jest zalecane z powodów omówionych poniżej).
Sprawdzone metody dotyczące aplikacji natywnej OAuth2
Niezależnie od wybranego podejścia (jest kilka kompromisów do rozważenia), należy zwrócić uwagę na najlepsze praktyki opisane tutaj dla aplikacji natywnych korzystających z OAuth2: https://tools.ietf.org/html/rfc8252
Rozważ następujące opcje
Domniemany
Czy powinienem używać ukrytego?
Cytując z sekcji 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
Przepływ niejawnej autoryzacji OAuth 2.0 (zdefiniowany w sekcji 4.2 protokołu OAuth 2.0 [RFC6749]) generalnie działa z praktyką wykonywania żądania autoryzacji w przeglądarce i otrzymywania odpowiedzi autoryzacyjnej poprzez komunikację między aplikacjami opartą na URI.
Ponieważ jednak niejawny przepływ nie może być chroniony przez PKCE [RFC7636] (co jest wymagane w sekcji 8.1), użycie Niejawnego przepływu z aplikacjami natywnymi NIE JEST ZALECANE .
Tokeny dostępu przyznane za pośrednictwem niejawnego przepływu również nie mogą być odświeżane bez interakcji użytkownika, co sprawia, że przepływ przyznawania kodu autoryzacji - który może wydawać tokeny odświeżania - jest bardziej praktyczną opcją dla autoryzacji aplikacji natywnych, które wymagają odświeżenia tokenów dostępu.
Kod autoryzacji
Jeśli zdecydujesz się na kod autoryzacji, jednym ze sposobów byłoby proxy za pośrednictwem własnego komponentu serwera internetowego, który wzbogaca żądania tokenu o klucz tajny klienta, aby uniknąć przechowywania go w aplikacji rozproszonej na urządzeniach.
Fragment poniżej z: https://dev.fitbit.com/docs/oauth2/
Przepływ Przyznanie kodu autoryzacji jest zalecany dla aplikacji, które mają usługę sieci Web. Ten przepływ wymaga komunikacji między serwerami przy użyciu klucza tajnego klienta aplikacji.
Uwaga: nigdy nie umieszczaj klucza tajnego klienta w kodzie rozproszonym, takim jak aplikacje pobrane za pośrednictwem sklepu z aplikacjami lub JavaScript po stronie klienta.
Aplikacje, które nie mają usługi sieci Web, powinny używać przepływu niejawnego przyznania.
Wniosek
Ostateczna decyzja powinna uwzględniać pożądane wrażenia użytkownika, ale także apetyt na ryzyko po przeprowadzeniu właściwej oceny ryzyka dla wybranych podejść i lepszym zrozumieniu konsekwencji.
Świetna lektura jest tutaj https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Inny to https://www.oauth.com/oauth2-servers/oauth-native-apps/, który stwierdza
Bieżąca najlepsza praktyka branżowa polega na korzystaniu z przepływu autoryzacji z pominięciem klucza tajnego klienta oraz przy użyciu zewnętrznego agenta użytkownika do ukończenia przepływu. Zewnętrzny klient użytkownika jest zwykle natywną przeglądarką urządzenia (z domeną zabezpieczeń oddzielną od aplikacji natywnej), dzięki czemu aplikacja nie może uzyskać dostępu do magazynu plików cookie ani sprawdzać lub modyfikować zawartości strony w przeglądarce.
Uwzględnienie PKCE
Powinieneś również wziąć pod uwagę PKCE, które jest opisane tutaj https://www.oauth.com/oauth2-servers/pkce/
W szczególności, jeśli wdrażasz również serwer autoryzacji, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ stwierdza, że należy
- Zezwalaj klientom na rejestrowanie niestandardowych schematów adresów URL dla ich przekierowań.
- Obsługa adresów URL przekierowań pętli zwrotnej IP z dowolnymi numerami portów w celu obsługi aplikacji komputerowych.
- Nie zakładaj, że aplikacje natywne mogą zachować tajemnicę. Wymagaj od wszystkich aplikacji, aby deklarowały, czy są publiczne, czy poufne, i wysyłaj klucze klienta tylko do poufnych aplikacji.
- Obsługuj rozszerzenie PKCE i wymagaj, aby używali go klienci publiczni.
- Spróbuj wykryć, kiedy interfejs autoryzacji jest osadzony w widoku sieci Web aplikacji natywnej, zamiast uruchamiać go w przeglądarce systemowej, i odrzuć te żądania.
Uwzględnienie widoków internetowych
Istnieje wiele przykładów korzystania z widoków internetowych, np. Wbudowanego klienta użytkownika, ale należy unikać tego podejścia (zwłaszcza gdy aplikacja nie jest własna), aw niektórych przypadkach może spowodować zakaz używania interfejsu API jako fragmentu poniżej stąd demonstruje
Każda próba osadzenia strony uwierzytelniającej OAuth 2.0 spowoduje zablokowanie aplikacji w Fitbit API.
Ze względów bezpieczeństwa strona autoryzacji OAuth 2.0 musi być prezentowana w dedykowanym widoku przeglądarki. Użytkownicy Fitbit mogą potwierdzić, że uwierzytelniają się na prawdziwej stronie Fitbit.com tylko wtedy, gdy posiadają narzędzia dostarczone przez przeglądarkę, takie jak pasek adresu URL i informacje o certyfikacie Transport Layer Security (TLS).
W przypadku aplikacji natywnych oznacza to, że strona autoryzacji musi otwierać się w domyślnej przeglądarce. Aplikacje natywne mogą używać niestandardowych schematów adresów URL jako identyfikatorów URI przekierowania w celu przekierowania użytkownika z powrotem z przeglądarki do aplikacji żądającej pozwolenia.
Aplikacje dla systemu iOS mogą używać klasy SFSafariViewController zamiast przełączać się na Safari. Używanie klasy WKWebView lub UIWebView jest zabronione.
Aplikacje na Androida mogą używać niestandardowych kart Chrome zamiast przełączać się na domyślną przeglądarkę. Korzystanie z WebView jest zabronione.
W celu dalszego wyjaśnienia, oto cytat z tej sekcji z poprzedniego projektu odnośnika do najlepszych praktyk podanego powyżej
Osadzone klienty użytkownika, powszechnie implementowane z widokami internetowymi, są alternatywną metodą autoryzacji aplikacji natywnych. Z definicji są one jednak niebezpieczne dla osób trzecich. Obejmują one logowanie użytkownika przy użyciu pełnych danych logowania, tylko po to, aby obniżyć ich zakres do mniej wydajnych poświadczeń OAuth.
Nawet gdy są używane przez zaufane aplikacje własne, wbudowane programy klienckie naruszają zasadę najniższych przywilejów, uzyskując silniejsze dane uwierzytelniające niż potrzebują, potencjalnie zwiększając powierzchnię ataku.
W typowych implementacjach wbudowanych agentów użytkownika, opartych na widoku sieci Web, aplikacja hosta może: rejestrować każde naciśnięcie klawisza wprowadzone w formularzu w celu przechwycenia nazw użytkowników i haseł; automatyczne przesyłanie formularzy i pomijanie zgody użytkownika; kopiować sesyjne pliki cookie i używać ich do wykonywania uwierzytelnionych działań jako użytkownik.
Zachęcanie użytkowników do wprowadzania poświadczeń we wbudowanym widoku internetowym bez zwykłego paska adresu i innych funkcji tożsamości, które mają przeglądarki, uniemożliwia użytkownikowi sprawdzenie, czy logują się do legalnej witryny, a nawet gdy są, szkoli ich że można wprowadzić poświadczenia bez uprzedniej weryfikacji witryny.
Oprócz obaw związanych z bezpieczeństwem, widoki internetowe nie dzielą stanu uwierzytelnienia z innymi aplikacjami lub przeglądarką systemową, co wymaga od użytkownika logowania się w przypadku każdego żądania autoryzacji i prowadzi do złego doświadczenia użytkownika.
W związku z powyższym NIE ZALECA SIĘ korzystania z wbudowanych klientów użytkownika, z wyjątkiem sytuacji, gdy zaufana własna aplikacja działa jako zewnętrzny agent użytkownika dla innych aplikacji lub zapewnia jednokrotne logowanie do wielu aplikacji własnych.
Serwery autoryzacji POWINNY rozważyć podjęcie kroków mających na celu wykrycie i zablokowanie logowania za pośrednictwem wbudowanych agentów użytkownika, które nie są ich własnymi, jeśli to możliwe.
Poruszono również kilka interesujących kwestii: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- za