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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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