Как сохранить ключ и секрет OAuth v1 для клиента Twitter с открытым исходным кодом, не раскрывая его пользователю?

Я хочу сделать толстый клиент, настольный компьютер, клиент с открытым исходным кодом для Twitter. Я использую .NET в качестве языка и Twitterizer в качестве оболочки OAuth / Twitter, и мое приложение, скорее всего, будет выпущено с открытым исходным кодом.

Чтобы получить токен OAuth, требуется четыре элемента информации:

1. Токен доступа (имя пользователя Twitter)
2. Секрет доступа (пароль твиттера)
3. Ключ потребителя
4. Потребительский секрет

Вторые две части информации не должны передаваться, как частный ключ PGP. Однако из-за того, как спроектирован поток авторизации OAuth, они должны быть в собственном приложении. Даже если приложение не было открытым исходным кодом, а ключ / секрет потребителя были зашифрованы, достаточно опытный пользователь мог получить доступ к паре ключ / секрет потребителя.

Итак, мой вопрос, как мне обойти эту проблему? Какова правильная стратегия для настольного клиента Twitter, чтобы защитить его ключ и секрет потребителя?

Я нашел ответ, который отражает путь, который я рассматривал, спускаясь по вселенной . В статье « Помимо потока перенаправления веб-страниц OAuth» предлагаются некоторые рекомендации, одним из которых является веб-URL, который проксирует процесс обмена токенами. Я должен найти способ правильно аутентифицировать, что мое приложение запрашивает аутентификацию на этой странице прокси. Однако это возможно.

Я могу ошибаться, но если вы связываете ключи с настольным или мобильным приложением, с открытым исходным кодом или нет, к ним можно получить доступ. Если такие службы, как Twitter и Tumblr, вынуждают нас использовать OAuth-only API, у нас есть два варианта:

• настроить службу прокси-сервера для каждого приложения
• связка ключей с приложением

Первый более сложный и дорогостоящий, не обязательно поддерживаемый для небольших приложений с открытым исходным кодом. Последнее означает, что приложение может и будет заблокировано, как только спамеры украдут ключи. Поскольку Twitter и Tumblr пока не дают лучшего варианта и привинчивают все настольные клиенты, включая клиентов с открытым исходным кодом, есть предложение распространять ключи «Big Fish» и использовать их в качестве запасного варианта .

Наконец, есть возможность заставить каждого пользователя получать ключи API.

Раздел 4.6 RFC 5849 , который определяет OAuth 1, гласит, что секрет потребителя никогда не предназначался для использования пользователями настольных компьютеров, несмотря на то, что он использовался Twitter на практике. Как отметил Нельсон Элхейдж в «Дорогом Твиттере », Твиттер может и действительно закрывает потребительские ключи настольных клиентов, при условии, что клиент не слишком большой, чтобы выйти из строя. Но есть два обходных пути, позволяющих использовать OAuth 1 в настольном или мобильном приложении.

Одним из способов является прокси весь протокол Twitter через сервер, на котором вы работаете. Таким образом, секретный ключ пользователя остается на вашем сервере. Это обходной путь, рекомендованный Диком Хардтом , редактором спецификации OAuth 1. Этот обходной путь не относится к стоимости эксплуатации этого сервера.

Другой способ, как было предложено в сообщении Раффи Крикоряна для группы разработчиков Google в Твиттере и в публикации Криса Стейппа в списке рассылки Википедии, состоит в том, чтобы «каждый пользователь зарегистрировал свою копию вашего настольного приложения в качестве своего собственного потребителя». Затем пользователь скопирует и вставит недавно зарегистрированный потребительский ключ и потребительский секрет в ваше приложение. Руководство для вашего приложения затем должно будет включать подробные инструкции о том, как зарегистрировать новое приложение на сайте разработчика Twitter. Это официальное ограничение имеет несколько практических проблем:

• Ваш клиент столкнется с недостатком удобства использования по сравнению с известными частными клиентами.
• Форма для создания нового приложения не появляется , чтобы предложить способ предварительно заполнить необходимые поля. Это означает, что вам придется обновлять руководство по регистрации в вашем руководстве всякий раз, когда Twitter изменяет процедуру регистрации приложения.
• Соглашение о разработке требует, чтобы пользователи были совершеннолетними, чтобы заключить обязывающий договор. Это означает, что пользователь вашего приложения в возрасте от 13 до 17 лет должен иметь родителей, принимающих соглашение от имени пользователя.
• Политика разработчиков Twitter запрещает массовую регистрацию приложений и «приседание имен», которое определяется как «отправка нескольких приложений с одной и той же функцией под разными именами». Мне неизвестен какой-либо прецедент относительно того, рассматривал ли Twitter несвязанных пользователей, которые зарегистрировали отдельные копии одного приложения, как «сквоттеры имен».

Я собираюсь ответить, но предупреждаю, что я сам не занимался этим, я отказываюсь от лучших практик и существующего соответствующего опыта;

Я бы не беспокоился об этом слишком сильно. Если ваш клиент с открытым исходным кодом, то он все равно будет иметь доступ к источнику, и попытка контролировать то, что они делают с вашей программой, в любом случае противоречит природе открытого источника (хотя важно то, что вы пытаетесь сделать, этого нет ).

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

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

Полное раскрытие, я не знаком с API Twitters, API твиттера, требованиями oauth или чем-то еще, что я сказал, что звучит сомнительно;)

Ключ потребителя и секрет привязаны к приложению, а не к пользователю. Благодаря этому провайдер OAuth знает, с каким приложением он имеет дело. Остальные, токен доступа и секрет будут получены после выполнения первых шагов.

См. Этот пост в блоге для получения дополнительной информации, поскольку он показывает, как работает протокол.