Oauth 2.0: идентификатор клиента и клиентский секрет, это проблема безопасности?

Когда клиентское приложение Android oauth 2.0 имеет свои учетные данные (идентификатор клиента и клиентский секрет), очень легко декомпилировать приложение и получить учетные данные.
Каковы последствия для выявления идентификатора клиента и секретности?

Ответ 1

Я знаю, что это не будет хорошим ответом StackOverflow, но я не могу объяснить это лучше, чем модель угрозы и соображения безопасности (RFC 6819). Итак, вот параграф о получении Client Secret и его относительных последствиях.

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

Также интересным для вашего примера является пример смартфонов.

Я знаю, что RFC - это не самое смешное чтение, но это довольно ясно.

Ответ 2

В соответствии с этим это проблема безопасности: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation

Если ссылка перестает работать, вот что она говорит:

Зависимость OAuth от авторизации на основе браузера создает проблему наследования для мобильных или настольных приложений, которые по умолчанию не запускаются в браузере пользователя. Более того, с точки зрения безопасности, основная проблема заключается в том, когда разработчики хранят и скрывают комбинацию ключ/секрет в самом клиентском приложении. Это делает поворот ключа практически невозможным и обеспечивает несанкционированный доступ к декомпилированному исходному коду или двоичному файлу, где хранится секрет потребителя. Например, чтобы скомпрометировать Client Credentials for Twitter Client на Android, злоумышленник может просто разобрать файл classes.dex с помощью инструмента для диссамблера Android dexdump:

dexdump - d classes.dex

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

Ответ 3

Просто замечание: идентификатор клиента не является секретом по дизайну, поэтому на самом деле нет необходимости его защищать.

См. раздел 2.2 в RFC 6749 ( "Рамка авторизации OAuth 2.0" ):

Идентификатор клиента не является секретом; он предоставляется владельцу ресурса и НЕ ДОЛЖЕН использоваться отдельно для аутентификации клиента.