OAuth - защита от совместного использования Ключа / Секрета потребителя и списка токенов доступа

Question

Я работал над настройкой поставщика услуг и увидел, что для отправки запроса от имени пользователя все, что, по-видимому, необходимо, - это Ключ / Секрет потребителя и Ключ / Секрет токена.

Что мешает потребителю зарегистрироваться у моего поставщика услуг, заставить некоторых пользователей санкционировать доступ к некоторым их данным, а затем передать маркер доступа и информацию о потребителе третьей стороне?

Это сводится к проблеме доверия, что мы должны доверять нашим потребителям, что они не будут этого делать? Есть ли какой-нибудь способ, которым мы можем предотвратить этот вид деятельности посредством какого-либо мониторинга? Мы хотим предоставить решение OAuth, но нам не нужно сильно беспокоиться о злонамеренном потребителе.

Спасибо за понимание.

Answer 1

В реализации Twitter OAuth участвуют четыре токена.

1. Ключ потребителя
2. Секретный ключ пользователя
3. OAuth Token
4. Секретный знак Oauth

В случае веб-приложения конечный пользователь никогда не имеет доступа к токенам 1 и 2, поскольку они никогда не передаются клиенту. Связь с API Twitter является межсерверной. В этом сценарии риск меньше.

В случае настольного приложения ключи «Consumer» обычно каким-то образом встроены в двоичный файл. Это общепризнанная проблема безопасности в реализации OAuth в Twitter. Решительный человек может декомпилировать / взломать / разблокировать практически любой двоичный файл, чтобы получить ваши Ключи потребителя.

Итак, чтобы ответить на ваш вопрос: в случае настольных / мобильных приложений это абсолютно вопрос доверия. В случае веб-приложений это не так.