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

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

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

  2. в мобильном приложении мы можем встроить webview в наше приложение. И легко извлечь поле пароля в webview, потому что приложение, которое запрашивает разрешение, на самом деле является "браузером". таким образом, OAuth в мобильном приложении не имеет преимущества, которое имеет клиентское приложение не доступ к учетным данным пользователя поставщика услуг?

3 82
security oauth oauth-2.0 google-api

3 ответа:

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

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

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

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

13

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

1. Клиент должен получить код авторизации непосредственно из пользователь, а не из сервиса

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

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

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

8

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

0