klucz klienta w OAuth 2.0

Aby korzystać z Google Drive API, muszę grać z uwierzytelnianiem przy użyciu OAuth2.0. Mam kilka pytań na ten temat.

1. Identyfikator klienta i klucz tajny klienta służą do identyfikacji mojej aplikacji. Ale muszą być zakodowane na stałe, jeśli jest to aplikacja kliencka. Tak więc każdy może zdekompilować moją aplikację i wyodrębnić ją z kodu źródłowego. Czy to oznacza, że ​​zła aplikacja może udawać dobrą aplikację, używając identyfikatora i tajnego identyfikatora klienta dobrej aplikacji? Czyli użytkownik pokazywałby ekran z prośbą o udzielenie pozwolenia na dobrą aplikację, mimo że w rzeczywistości jest o to pytana przez złą aplikację? Jeśli tak, co mam zrobić? A może właściwie nie powinienem się tym martwić?

2. W aplikacji mobilnej możemy osadzić w naszej aplikacji podgląd sieciowy. A wyodrębnienie pola hasła w widoku internetowym jest łatwe, ponieważ aplikacja prosząca o pozwolenie jest w rzeczywistości „przeglądarką”. Czyli OAuth w aplikacji mobilnej nie ma takiej korzyści, że aplikacja kliencka nie ma dostępu do danych uwierzytelniających użytkownika dostawcy usług?

Zacząłem pisać komentarz do twojego pytania, ale potem odkryłem, że jest za dużo do powiedzenia, więc oto moje poglądy na ten temat w odpowiedzi.

1. Tak, istnieje realna możliwość i było kilka opartych na tym exploitów. Sugeruje się, aby nie utrzymywać aplikacji w tajemnicy w swojej aplikacji, jest nawet część specyfikacji, że aplikacje rozproszone nie powinny używać tego tokena. Teraz możesz zapytać, ale XYZ wymaga tego, aby działać. W takim przypadku nie implementują poprawnie specyfikacji i nie powinieneś A korzystać z tej usługi (mało prawdopodobne) lub B spróbować zabezpieczyć token przy użyciu pewnych metod zaciemniających, aby utrudnić znalezienie lub używanie serwera jako proxy.

   Na przykład w bibliotece Facebooka na Androida było kilka błędów, w których wyciekały tokeny do Logów, możesz dowiedzieć się więcej na ten temat tutaj http://attack-secure.com/all-your-facebook-access-tokens-are-belong -do-nas i tutaj https://www.youtube.com/watch?v=twyL7Uxe6sk . Podsumowując, zachowaj szczególną ostrożność podczas korzystania z bibliotek stron trzecich (w rzeczywistości zdrowy rozsądek, ale jeśli przejęcie tokenów jest Twoim dużym problemem, dodaj kolejny dodatek do ostrożności).

2. Od dłuższego czasu narzekałem na temat punktu 2. Zrobiłem nawet pewne obejścia w moich aplikacjach, aby zmodyfikować strony zgody (na przykład zmienić powiększenie i projekt w celu dopasowania do aplikacji), ale nic nie powstrzymało mnie przed odczytaniem wartości z pól w widoku sieciowym z nazwą użytkownika i hasłem. Dlatego całkowicie zgadzam się z drugim punktem i uważam to za duży „błąd” w specyfikacji protokołu OAuth. Chodzi o to, że „aplikacja nie uzyskuje dostępu do danych uwierzytelniających użytkownika” w specyfikacji jest tylko marzeniem i daje użytkownikom fałszywe poczucie bezpieczeństwa… Myślę też, że ludzie są zwykle podejrzliwi, gdy aplikacja prosi ich o podanie danych logowania na Facebooku, Twitterze, Dropbox lub innych. Wątpię, by wielu zwykłych ludzi czytało specyfikację OAuth i mówiło „Teraz jestem bezpieczny”, ale zamiast tego kierują się zdrowym rozsądkiem i generalnie nie używają aplikacji, którym nie ufają.

Miałem to samo pytanie, co pytanie 1 tutaj i przeprowadziłem niedawno pewne badania i doszedłem do wniosku, że nie należy utrzymywać „klienta w tajemnicy” w tajemnicy. Typ klientów, którzy nie zachowują poufności informacji o kliencie, jest określany jako „klient publiczny” w specyfikacji OAuth2. Poniższe fakty zapobiegają możliwości uzyskania przez osobę złośliwą kodu autoryzacji, a następnie tokenu dostępu.

1. Klient musi otrzymać kod autoryzacyjny bezpośrednio od użytkownika, a nie od serwisu

Nawet jeśli użytkownik wskaże usługę, której ufa klientowi, klient nie może uzyskać kodu autoryzacji z usługi po prostu pokazując identyfikator klienta i sekret klienta. Zamiast tego klient musi otrzymać kod autoryzacyjny bezpośrednio od użytkownika. (Zwykle odbywa się to przez przekierowanie adresu URL, o czym opowiem później). Tak więc w przypadku złośliwego klienta nie wystarczy znać identyfikator / sekret klienta, któremu zaufał użytkownik. Musi w jakiś sposób zaangażować lub sfałszować użytkownika, aby podał mu kod autoryzacji, co powinno być trudniejsze niż zwykła znajomość identyfikatora / tajemnicy klienta.

2. Adres URL przekierowania jest zarejestrowany z identyfikatorem / sekretem klienta

Załóżmy, że złośliwy klient w jakiś sposób zdołał zaangażować użytkownika i zmusić go do kliknięcia przycisku „Autoryzuj tę aplikację” na stronie usługi. Spowoduje to wywołanie odpowiedzi przekierowania adresu URL z usługi do przeglądarki użytkownika wraz z kodem autoryzacji. Następnie kod autoryzacyjny zostanie wysłany z przeglądarki użytkownika na adres URL przekierowania, a klient powinien nasłuchiwać adresu URL przekierowania, aby otrzymać kod autoryzacji. (Adresem URL przekierowania może być również localhost i doszedłem do wniosku, że jest to typowy sposób, w jaki „klient publiczny” otrzymuje kod autoryzacji). Ponieważ ten adres URL przekierowania jest zarejestrowany w usłudze z identyfikatorem / sekretem klienta, złośliwy klient nie mają sposób kontrolowania, gdzie jest przekazywany kod autoryzacji.

Odpowiedź na drugie pytanie: interfejsy API Google ze względów bezpieczeństwa upoważniają do uwierzytelniania / logowania się w samej aplikacji (np. Przeglądanie stron internetowych jest niedozwolone) i musi być wykonywane poza aplikacją za pomocą przeglądarki, aby zapewnić większe bezpieczeństwo, co jest dokładniej wyjaśnione poniżej: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html