секрет клиента в OAuth 2.0

Чтобы использовать google drive api, мне нужно поиграть с аутентификацией с помощью OAuth2.0. И у меня есть несколько вопросов по этому поводу.

1. Идентификатор клиента и секрет клиента используются для определения моего приложения. Но они должны быть жестко запрограммированы, если это клиентское приложение. Итак, каждый может декомпилировать мое приложение и извлечь их из исходного кода. Означает ли это, что плохое приложение может притвориться хорошим, используя идентификатор и секрет клиента хорошего приложения? Таким образом, пользователь будет показывать экран, на котором запрашивается разрешение на хорошее приложение, даже если оно действительно запрашивается плохим приложением? Если да, что мне делать? Или мне вообще не стоит об этом беспокоиться?

2. В мобильном приложении мы можем встроить веб-просмотр в наше приложение. А поле пароля в веб-просмотре легко извлечь, потому что приложение, запрашивающее разрешение, на самом деле является «браузером». Итак, OAuth в мобильном приложении не имеет того преимущества, что клиентское приложение не имеет доступа к учетным данным пользователя поставщика услуг?

Я начал писать комментарий к вашему вопросу, но потом обнаружил, что сказать слишком много, поэтому в ответе я изложу свое мнение по этому поводу.

1. Да, для этого есть реальная возможность, и на основе этого были некоторые эксплойты. Предлагается не хранить приложение в секрете в своем приложении, в спецификации даже есть часть, что распределенные приложения не должны использовать этот токен. Теперь вы можете спросить, но XYZ требует этого для работы. В этом случае они не реализуют спецификацию должным образом, и вам не следует A использовать эту службу (маловероятно) или B пытаться защитить токен с помощью некоторых методов обфускации, чтобы затруднить поиск или использование вашего сервера в качестве прокси.

   Например, были некоторые ошибки в библиотеке Facebook для Android, где происходила утечка токенов в журналы, вы можете узнать больше об этом здесь http://attack-secure.com/all-your-facebook-access-tokens-are-belong - нам и здесь https://www.youtube.com/watch?v=twyL7Uxe6sk . В общем, будьте особенно осторожны при использовании сторонних библиотек (на самом деле здравый смысл, но если захват токенов - ваша большая проблема, добавьте еще одну дополнительную осторожность).

2. Я довольно давно разглагольствовал по поводу пункта 2. Я даже применил некоторые обходные пути в своих приложениях, чтобы изменить страницы согласия (например, изменив масштаб и дизайн в соответствии с приложением), но ничто не мешало мне читать значения из полей внутри веб-представления с именем пользователя и паролем. Поэтому я полностью согласен с вашим вторым пунктом и считаю это большой «ошибкой» в спецификации OAuth. То, что «приложение не получает доступ к учетным данным пользователей» в спецификации, является просто мечтой и дает пользователям ложное чувство безопасности ... Также я предполагаю, что у людей обычно возникают подозрения, когда приложение запрашивает их учетные данные Facebook, Twitter, Dropbox или другие. Я сомневаюсь, что многие обычные люди читают спецификацию OAuth и говорят: «Теперь я в безопасности», но вместо этого руководствуйтесь здравым смыслом и, как правило, не используют приложения, которым они не доверяют.

У меня был тот же вопрос, что и в вопросе 1 здесь, и я недавно провел небольшое исследование, и я пришел к выводу, что это нормально - не держать в секрете «секрет клиента». Тип клиентов, которые не сохраняют конфиденциальность секрета клиента, в спецификации OAuth2 называется «публичный клиент». Вероятность того, что кто-то злоумышленник сможет получить код авторизации, а затем токен доступа, предотвращается следующими фактами.

1. Клиенту необходимо получить код авторизации напрямую от пользователя, а не от сервиса.

Даже если пользователь указывает службу, которой он / она доверяет клиенту, клиент не может получить код авторизации от службы, просто указав идентификатор клиента и секрет клиента. Вместо этого клиент должен получить код авторизации непосредственно от пользователя. (Обычно это делается с помощью перенаправления URL, о чем я расскажу позже.) Итак, для злонамеренного клиента недостаточно знать идентификатор / секрет клиента, которому доверяет пользователь. Он должен как-то вовлечь или обмануть пользователя, чтобы дать ему код авторизации, что должно быть сложнее, чем просто знать идентификатор / секрет клиента.

2. URL-адрес перенаправления зарегистрирован с идентификатором / секретом клиента.

Предположим, что злоумышленнику каким-то образом удалось вовлечь пользователя и заставить его нажать кнопку «Авторизовать это приложение» на странице сервиса. Это вызовет ответ перенаправления URL-адреса от службы в браузер пользователя с кодом авторизации с ним. Затем код авторизации будет отправлен из браузера пользователя на URL-адрес перенаправления, и предполагается, что клиент прослушивает URL-адрес перенаправления для получения кода авторизации. (URL-адрес перенаправления тоже может быть localhost, и я решил, что это типичный способ, которым «общедоступный клиент» получает код авторизации.) Поскольку этот URL-адрес перенаправления зарегистрирован в службе с идентификатором / секретом клиента, злонамеренный клиент не есть способ контролировать, где предоставляется код авторизации.

Отвечая на второй вопрос: API Google по соображениям безопасности предписывают, что аутентификация / вход в систему не может выполняться в самом приложении (например, веб-просмотр не разрешен) и должен выполняться вне приложения с использованием браузера для большей безопасности, что дополнительно объясняется ниже: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html