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

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

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

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

82
google-api oauth oauth-2.0 security

3 ответов

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

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

    например, были некоторые ошибки в библиотеке 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 spec и говорят: "теперь я в безопасности", но вместо этого используют здравый смысл и вообще не использовать приложения, которым они не доверяют.

13

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

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

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

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

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

8

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

0